Re: [squid-users] SSL rev proxy, redirector, 302 problems

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