See
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#ProxyPassReverseCookieDomain
Because the path is attached to a cookie, the mitigation I described above - just making sure that IIRF also proxies the script and image requests and so on - will not apply. A cookie with a wrong path won't result in a request through to IIRF, so there's nothing you can configure in IIRF to make things right, when the Cookie path is wrong.
There are some ways I can think of to avoid this problem:
- Don't use cookies with relative paths when proxying requests
- The server can be smart about setting cookies, examining the Via header, which indicates how the incoming request was proxied. This requires modification of the target server, in your case the /logviewer app.
- Don't modify the URL path of requests across proxies
Avoidance #3 is probably easiest in your case. Instead of using /test, use /logviewer in the public, exposed URL.
- Getting IIRF to do the work
It may be possible to modify IIRF to do this work intelligently - in other words to examine the response that flows back for the presence of a Set-Cookie header. If one is found, IIRF could modify the path of the cookie (if present) to the path used for the public, external request.
Upon quick consideration, this seems like a relatively benign change, and it should be simple to implement. I'll need to think about it further, though, before I am ready to conclusively say it will be easy and benign.
For now you have a way to get things to work without that change.