On Fri, 5 Dec 2003, Jesse Reynolds wrote: > We change the hostname and port of the URL in the redirector. We have > to do this because we have different backend web servers for > different paths (eg www.host.com/app1 is redirected to > internalhost.host.com:8080/app1 ) > > Isn't this the purpose of a rediretor when squid is in accelerator mode?
It is, but where possible I prefer making the accelerator setup in such manner that a redirector is not needed. You need redirectors if you need to modify the URL-path, and if not using the cache_peer approach discussed if the port differs or if different URL-paths on the same domain to different servers. In Squid-3 or if using the cache_peer approach to forwarding then you only need redirectors if you need to modify the URL-path of the request. There has been a lot of effort in the 'rproxy' project for making accelerator setups easier and more flexible and much of this has found it's way into Squid-3.0. The basic principle is that you set up connections to the web servers using cache_peer (+ never_direct if using 2.5) and then select which web server to forward the request to via cache_peer_access. > >Another option which you might be able to try is to rewrite the URLs into > >https:// and configure the web server as a parent proxy (but remember to > >disable server-side persistent connections). This will make Squid send the > >full URL to the server including protocol, not only the URL-path + query. > > Ah, interesting. Can you do this in combination with a redirector to > separate different path to host relationships? Yes. > Wouldn't the web server try and encrypt the response if it gets a https? > Or does it decide whether to encrypt or not based other headers? The web server decides to encrypt or not based on how the connection was established, not on the request/response data. SSL will be used if the connection was established using SSL. What should be noted however is that not all web servers accept requests using a full URL even if the HTTP standards say they should. Also, it is possible the extra information will just be ignored by the web server without making it available to applications etc, but if you can modify the web server then modifying it to deduce the correct protocol, host etc from the URL if receiving a full URL would solve this kind of accelerator problem quite nicely. Note: The front-end-https functionality is available for Squid-2.5 as part of the SSL update available from http://devel.squid-cache.org/ but is intended to be used with the improved forwarding configuration of Squid-3 and only works in cache_peer based forwarding setups. Regards Henrik
