www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [PATCH] fixes & cleanups
Date Fri, 23 Mar 2001 21:42:41 GMT
Ian Holsman wrote:

> foo.bar.com  is the main host
> candy.bar.com is the reverse proxyied host
> 
> if candy.bar.com sets a cookie while being r-proxied via foo, it gets
> passed back to the browser. this is good.
> 
> the problem is the next time I set the same cookie from candy.bar  I see
> that I now have 2 cookies, each
> with the same name, which I don't think is legal.

Keep in mind the potential website name confusion that can happen when
setting cookies.

The browsers are quite strict (now anyway) with making sure that a
cookie set by website A is only ever returned to website A, and never
any other website.

Where the confusion comes in is when you have a webserver and a reverse
proxy. Your browser only ever sees the reverse proxy - it has no clue
whatsoever that a backend server exists. It has no idea what kind of
webserver it is, and has no idea what the backend server is called. As
far as your browser is concerned, only one website exists - the reverse
proxy.

The backend webserver on the other hand has no idea what the reverse
proxy is called, and cannot tell the difference between a browser and a
reverse proxy (or any other kind of proxy).

To clear up this confusion, you need to always reference your cookies as
if they orginated from the reverse proxy. In your example, this means
that a cookie set on candy.bar.com must think that it is actually
foo.bar.com - otherwise the browser sees the cookie, goies "who the hell
is candy.bar.com?" and turfs the cookie.

Where two cookies were set with the same name, this was perfectly legal
- because the cookies were set by two different hosts - foo.bar.com, and
candy.bar.com. You know they are the same website, but your browser has
no clue. As far as your browser is concerned they are two websites with
different names that work the same.

The most important thing to do when working with reverse proxies is to
make 200% sure that the reverse proxy cannot be bypassed. This can most
often happen with redirections - candy.bar.com will send a redirect to
http://candy.bar.com/somewhere/, which jumps your browser off of
foo.bar.com and onto candy.bar.com, breaking all your cookies and
causing mayhem. Correctly setting the ProxyPassReverse directive for
each ProxyPass will make sure this does not happen.

An excellent debugging tool is something like tcpflow, which records tcp
conversations over an interface. By sniffing the interface on the
reverse proxy, you can determine exactly what the backend server and the
frontend browser are saying to each other via the reverse proxy, which
will quickly uncover any problems you may have with things that should
be working but aren't.

Good luck!

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Mime
View raw message