Mar 16, 2011 at 1:11 AM
Edited Mar 16, 2011 at 1:14 AM
I don't know exactly what you mean by "partially encrypted". I am thinking that you mean that IE is complaining that some of the content is not being delivered over a secure channel. I've seen this message, though I don't recall the exact syntax
or text of the message.
If this is what you mean, then I will make a guess as to the reason . If I understand your scenario correctly, you are using a secure channel (https) between the browser and the IIS/IIRF server. Then, in some cases you are proxying
over an insecure channel from the IIRF filter to an Apache application. the content this application renders is then returned directly to the requesting browser, which is what you want a transparent proxy to do.
Now suppose that the content itself employs non-relative links in it, which refer to images, stylesheets, XML content, or other stuff; If IIRF requests the service over http://192.168.xx.yy on behalf of the original
client, then the apache app may generate references to such resources using the same URL prefix. In other words, within the HTML content there may be a reference to a stylesheet that looks like this:
<link rel="stylesheet" type="text/css" href='http://192.168.xx.yy/styles/reset.css'>
If that is the case, then a browser that connects to the service via a proxy over https will see that link in the page content as a directive to download the referenced stylesheet over an insecure channel (not https), and the browser will notify you,
the user, of the discrepancy between the originally specified protocol (https) and the protocol it is being asked to use for this style (http).
To determine if this is happening, I suggest you do a "view source" on the content in the browser, and search for non-relative links. Any link or reference with an http: in it will be a clear indication that the service is generating content pages that
contain non-relative links.
The fix for this is to make sure that the proxied app emits links only in relative form. Relative links will be relayed to any client that accesses the service, and will be correctly interpreted by the client as being consistent with its original
request, whether the client connects to the service via a proxy (over HTTPS or not) or connects directly (over HTTPs or not).
There is nothing to change in the IIRF rules to fix this. You'd need to fix your app.
IF I have misunderstood what you are describing, then it's a different story. But for that, please clarify the problem you're having.