On Sun, Jul 25, 2010 at 12:18:53AM +0200, [email protected] 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
