[squid-users] Re: Squid: 2.5 as reverse proxy?

From: Henrik Nordstrom <[email protected]>
Date: 11 Dec 2002 21:01:03 +0100

Standard Squid can be used and is used by many as a reverse proxy. But
it cannot do exactly what you ask for, but there is other ways to
configure things to avoid such issues (see below).

The Squid reverse proxy development branch is an effort to make Squid
easier to use as a reverse proxy and to extend Squid with additional
functions which is useful in a reverse proxy scenario such as support
for authentication at the reverse proxy, divided URL space per
cache_port, Location header rewrites and many other things. See
http://devel.squid-cache.org/rproxy/ for details.

The "rproxy" development branch is currently based on Squid-2.6.DEVEL.

Now back to Squid in general:

In Squid mapping of URL space is normally done via redirectors. A
redirector is a small helper process receiving URLs as input and sending
back modified URLs as output. This function is available in all Squid
versions.

But if possible I would advice to NOT rewrite URLs. A better method
unless absolutely have to rewrite the URLs is to set up your backend
servers as non-ICP cache peers to Squid and tell Squid that it must not
go direct. Then use cache_peer_access to control which URLs may be sent
to which server to divide the URL space among your servers. This may
require some reconfiguration of the real servers to add virtual servers
for the domains the users are requesting, but avoids a big tangle of URL
issues uncluding the Location header..

Location headers is only one specific aspect of the problems seen when
rewriting URLs in a reverse proxy. You also have to care about CGI
programs or server plugins rendering full URLs into returned HTML
content, WebDAV clients sending additional headers with full URLs in the
requests and many other things. All of this goes away naturally if the
same URL is used on the backend server.

Note: standard Squid assumes all your cache peers are proxies which may
confuse certain HTTP/1.0 web servers if you use the cache_peer
technique. Most servers (including Apache) works fine however, so it is
not such a big problem.

Regards
Henrik

ons 2002-12-11 klockan 17.49 skrev Michael.Schroepl@telekurs.de:
>
> Hello Henryk,
>
> please apologize that I don't dig myself through the Squid websites to look
> for the apporipriate discussion group or mailing list ... you may well bash
> me for that if you want. I have a (hopefully) simple question about Squid
> 2.5 being used as reverse proxy. Looking at the project description
> (top-ranked Google hit), I found that's your baby, so I dare to mail you
> directly ...
>
>
>
> Does Squid 2.5 yet fully support acting as a reverse proxy?
>
> The project description at
> http://devel.squid-cache.org/projects.html#rproxy told me "beta testing"
> and didn't tell me whether this is already shipped with some official Squid
> version. There is a CVS tag for it, but I would rather not try and collect
> all these CVS files and find out which version this actually might be ...
> (change dates sounded like several months back).
>
>
>
> We want to do the following: Having Squid accessed via HTTP with an IP
> adress in the "Host:" header, then make Squid overwrite this by some
> distinct "Host:" header with a DNS name and route the request to some
> Apache server standing in a different network segment. (Our customer knows
> 'his' IP adress, as it is inside his network segment, and he isn't able of
> running DNS nor using hosts files, it's nothing but a mess - and we want
> him to migrate to another machine with a different version of the
> application we run for him, so we just plan to exchange his old Apache
> machine for a Squid 'routing' them to the new machine, thus they won't
> actually see a difference except for the content.)
>
> Basically, the scenario mentioned above works nicely - we selected to
> accelerate just one single host, the Apache receives the correctly
> translated "Host:" headers, and the appropriate virtual host is selected
> there. But this Apache may return all kinds of things, including cookies
> and redirections. To my surprise, the cookies actually do work, but the
> "Location:" header still contains the DNS name that we made Squid add when
> translating the incoming request (the Apache is using virtual hosts), and
> this DNS name is not understandable in the client's universe where they
> know nothing but the IP adress they started with.
>
> So we need Squid to translate the "Host:" name inside the "Location:"
> header back to the IP adress that has been used when accessing Squid in the
> first place. Apache doesn't know that Squid modified the "Host:" header, so
> it cannot do anything helpful here.
>
> We are using this mechanism in a similar context, there embedding an Apache
> into the URL space of another Apache via mod_proxy. I believe we don't have
> the redirection issue there, so we have not yet tried whether mod_proxy
> would be able to do what we want. But as all we need here is setting up
> some redirector, I would much prefer having Squid machine doing this (and
> caching some of the content, by the way) than installing an Apache just for
> using its mod_proxy feature.
>
> Do we have a chance to make Squid do what we need? If so, which directives
> did we miss? URLs or search terms might suffice to help us; a clear "no"
> could save us a lot of time.
>
>
>
> Regards, Michael
>
Received on Wed Dec 11 2002 - 13:01:20 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:12:02 MST