1. First Up
Well no, just to be clear: HTTPS is not (or was not) a "minor" part of the problem. HTTPS was THE problem exhibited in the logfile you sent earlier. It may be true now that you have reconsidered your use of HTTPS and decided you do not need it
in this case. Regardless, incorrect configuration of HTTPS was in fact the reason for the failure of your original attempt to proxy a request with IIRF.
Now, having removed HTTPS from the system, you see another, different failure, which , like the original problem, prevents the proxy from succeeding. But that does not mean that HTTPS was not the problem, originally.
2. About proxies
Regarding your current problem, Proxying can be tricky.
2.1 Simple cases
In the simplest case, a browser makes a request, the proxy (IIRF) relays the request to a different target server, then relays the response to the original requestor. This is easy.
2.2 Hostnames in the response headers
In some cases, there are ways for the hostname of the proxied site to leak into the response. This happens if the response sets one or more of the following http response headers: Location, Content-Location, or URI. This usually breaks the proxy
transaction, because the target of the proxied request is inaccessible to the original requestor. To handle this slightly more tricky case, you need to use a ProxyPassReverse directive; this tells IIRF to do the appropriate substitution of hostnames.
Then, when the original requestor trues to access those URLs, it goes through the IIRF proxy, as necessary. This takes care of 80% of the issues in proxied requests.
2.3 Hostnames Embedded in URL references
There are other ways the hostname of the proxy target can leak into the response. For example, an anchor tag generated by the proxied server may hard-code a hostname. (<a href='http://foo/bar'>). This may also happen with links to stylesheets,
scripts, and other assets. Once again, this will break proxied transactions, because the hostname is not accessible to the original requestor. The way to correct this is to remove hard-coded hostnames from the generated response.
2.4 Absolute and relative URL paths
Your problem is an example of a different category of issue in proxy operations - that relating to URL paths. In many cases a URL is specified without a hostname - this is normally how a generated page would refer to required CSS stylesheets, related
pages, scripts, images, and so on. URL's for any of those assets can use absolute or relative paths. an absolute path begins with a / and includes the complete URL path. To resolve such a path, user agents prepend the hostname and scheme used for the
For example, imagine a script tag in the HTML like so:
This is an absolute path - it begins with a slash. Suppose this page was requested as
Now, suppose the page containing that script tag was requested from
In contrast, a relative URL path does not start with a / . To resolve such a path, user agents prepend the scheme, hostname, and current relative path.
In the above example, supposing the script tag is constructed like this:
(no leading slash)
In other words, the URL path used to request the page, affects the resolved URLs for assets with relative URLs.
3. Proxied requests and Relative URL paths
When using IIRF (or any transparent HTTP proxy) to proxy requests, it is possible to modify the scheme, host, and/or URL path. For example, suppose there is a resource available at HTTPS, at host internal.example.com. The normal full URL would be:
You could configure IIRF to expose that restricted resource through a transparent (Reverse) proxy, so that requests to
...get proxied to the restricted Resource.aspx on the internal network.
In this case the proxy transaction modifies the scheme (https --becomes--> http), the hostname (internal.example.com ---becomes---> example.com), and and the resource name (Resource.aspx ---becomes--> Something.aspx). But the URL path to the
resource remains unchanged (/Restricted).
When the path is unchanged, it means that relative URL references in the response that flows through the proxy all still "work" without modification or intervention. (See section 2.4 above)
On the other hand it is also possible for administrators to specify a ProxyPass directive that modifies the URL path, as well as the scheme and hostname. For example you could specify a rule to proxy
In this case, any relative paths that are included in the response that flows back through the proxy, will not work properly. I hope it's clear why. If not, read section 2.4 of this message again.
ProxyPass ^/(.*)$ https://126.96.36.199/logviewer/
..does this. It changes the URL path of the request.
There are ways to get around the problem of broken relative URL references when the URL path changes. A simple way is to *also* proxy the secondary requests that are generated from relative URL references. These are requests for scripts,
images, and so on, that use a relative URL. This is often pretty straightforward to do with another ProxyPass rule, or a more general ProxyPass rule.
If you have a good understanding of when and where relative URL references appear in the HTTP response, it's easy to craft the proxypass rule to handle them. IF you don't have a good understanding, then you can hook up Fiddler and you can see the requests
flowing through to IIRF, and you will easily see which secondary requests need to be proxied.
4. Proxies and Cookies
Your problem is a slightly different wrinkle of that situation. In your case the relative URL path appears in the Cookie, not in a URL reference.
The actual page thinks it is running at a URL path of /logviewer, but you've proxied it so that the path that is apparent to the browser is /test. On a successful login, the actual page injects a cookie with the path it knows about: /logviewer, and the browser
stores and retains that cookie.
When the browser sends its next request, it *believes* it is sending the request to /test/Something , which means it also sends along Cookies designated for the URL path /test . Meanwhile, the actual cookie the browser received is rooted at the /logviewer
path. Because the /logviewer label on the cookie doesn't match the /test path in the request, the browser does not send out that Cookie with the followup request. The result is the server on the other side of the proxy sees no cookie, and thus concludes
there is no prior state held by the browser, and so asks the browser to login again. This is the symptom you're reporting.
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:
2. 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.
3. 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.
# NO NO NO
# YES YES YES
5. 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.