On 8/10/2013 4:22 a.m., John Gardner wrote:
This email has been classified as: NOT PROTECTIVELY MARKED This email has been classified as: PROTECT I wonder if someone can help me out with an issue that has come to light with a new application we are running behind our Squid 2.6 Reverse Proxy Server.
Please upgrade. 2.6 is now unable to cope with many web applications which are starting to assume or require HTTP/1.1 functionality.
At the moment we have a situation shown below; INTERNET ---> |FIREWALL1| ---> |REVERSE-PROXY| ---> |FIREWALL2| ---> APPLICATION WEB SERVER For all applications, Traffic comes in on HTTPS (and HTTP as well, but mostly HTTPS) from the Internet, passes through FIREWALL1 and then offloads the SSL at the REVERSE-PROXY, then the rest of the traffic flows as HTTP through FIREWALL2 and onto the APPLICATION WEB SERVER. This works for all of the sites we've been serving for the past two years, but for this particular new application, if you connect using https://my.server.com when the app redirects, Squid appears to go to http://my.server.com i.e. it does not stay encrypted. I've found a similar problem in this post using mod_proxy (http://serverfault.com/questions/388927/apache-reverseproxypass-redrects-to-http-rather-than-https)
This is not clear what you are saying the problem is. With properly configured Squid the proxy->server connection should be passing request through exactly as the client delivered them so te server apps have full and correct details to work from.
Are you able to share the squid.conf contents? that will help clarify what the proxy is actually doing vs what you think it should be doing.
Amos
