On Sun, Jul 25, 2010 at 12:18:53AM +0200, haproxy#serverphorums.com wrote:
> Thanks again for the response,
>
>
> I've come across some documentation for my app being used with a hardware appliance and the only config done on the app side is to disable ssl, which it currently is in my test set up. I found this important piece of info in the documentation also.
>
> A third iRule is used to rewrite the response from the application so SSL offloading
> can work. This iRule performs two functions, first it removes the Pragma header
> from the response, this header can cause problems when used as part of an
> encrypted connection.
Till there, OK.
> The second function is selectively implementing the
> stream replace. It is important to only modify text/html content.
Ahhhhhh!! but this is terribly dirty and unreliable. When some URLs are built from concatenation of two strings, this will not work, when they are built from JS, this will not work either. When parameters are to be passed to other URLs or components, this will not work. In fact there are quite a bunch of cases where this is unreliable, so you really have to configure the application to emit correct URLs. This also prevents you from sending compressed data.
If there is no http<->https switching required from the application, the best thing to do is to use only relative URLs. If the application has to know its address, then configure it to announce the public URL and not the private one nor the one deduced by the server. Also, check your server's doc, it is possible that it knows how to automatically switch to HTTPS URLs if it sees a specific header in the request. Some servers do that. If that's the case, simply add the header from haproxy using a "reqadd" rule.
Regards,
Willy
Received on 2010/07/25 12:50
This archive was generated by hypermail 2.2.0 : 2010/07/25 13:00 CEST