On 23-2-2011 0:08, Leif Hedstrom wrote:
On 02/22/2011 03:53 PM, Jorn Argelo wrote:
Dear all,
We are investigating a potential migration from Squid to ATS. On the
first look most of the stuff we use Squid for is available in ATS,
but I have a couple of questions about the remaps for a reversed
proxy ATS:
1) The documentation states that the port in both URLs must be the
same. If I understand it well, this means I cannot connect to port 80
on ATS and have, for example, port 50888 listening on my origin
server and use ATS to connect to the origin server. Is this correct?
If it's not correct, how would I put it in the remap.config?
The documentation is wrong, blame Igor :). Seriously though, we should
fix that doc bug, this has caused confusion before. You are most
certainly able (and encouraged) to map from one port to the other. I
do this all the time, on my "production" box, to hide Apache HTTPD
from outside access. The map rule would look exactly as you expect, e.g.
map http://www.example.com http://localhost:8888
Ok, good to know, thanks!
2) Is there any way of splitting the remap.config in multiple files?
This for manageability of remaps and redirects.
Not right now. At least not inside any of the "core" code. What I'd
suggest (and has been done before) is to do this yourself, e.g. simple do
cat /some/path/*.config >
/usr/local/etc/trafficserver/remap.config && traffic_line -r
Didn't think of that one, good idea. Will definitely use that.
3) Squid's cache peer construction allows direct connection to an
origin server using the host header provided by the client. And,
based on the acl, you can let Squid decide to what cache peer it
needs to connect to based on the Host header. How does this work with
ATS? I understood from the documentation that the remap.config is
also used for reversed proxy mode, but I still need to provide a
target (internal) URL. In our current setup the internal and public
URL are the same so I don't think this will work then? Since we have
nothing to fill in as target URL.
Not sure I understand this. You will need to map something like
map http://www.example.com/ http://localhost:8888
The default configuration as of current trunk (might be in v2.1.5 as
well) is to preserve the Host: header as sent to the origin server.
you can override that in records.config (look for the configuration
for "pristine host header").
Yes I sorta thought I was a bit vague on this one, but let me describe a
more practical scenario:
We have a typical setup, where www.example.com is used both internally
and externally, and both internal and external are using the same squid
installation to access the website. I guess this is a typical standard
setup really, but just to make sure it's clear:
(internet/internal) -> squid -> apache
Apache is responding on www.example.com, but DNS-wise www.example.com is
pointing to squid internally and externally.
So my question is: How would I achieve the same in ATS? Setting the
pristine host header config is clear, but it is not clear to me how I
achieve a similar setup in the remap.config:
map http://www.example.com http://???????
What do I fill in at the question marks? Because we only know of
www.example.com as nothing else is used in terms of URLs / host headers.
4) I am still not sure what the use of the reversed_map is and when I
am supposed to use it, even though I read the documentation several
times. Can someone please clarify this?
It's intended to be used when a server return redirects / location
information back to the user, to make sure that the user goes through
the proxy and not directly to the origin server. If you do not produce
any such information (which would be the case if you have the backend
respond / use the same URLs as the proxy, and use pristine host
headers), then it's not an issue. If however the HTTPD daemon could
e.g. return a header with a 302 response and Location: localhost:8888,
then you will need the reverse_map to handle it).
Ah, ok, clear. In our case we would always use pristine host headers and
won't be relevant for us then.
Cheers,
-- leif
Thanks for your feedback Leif.
Jorn
