[Fwd: Re: bug with virtual web servers]

attached mail follows:

Russ Daigle wrote:
>
> Henrik, thanks for your quick reply. I have found the statement in the
> http/1.1 rfc that states any host in the URI takes precedence over any host
> specified in a host header.
>
> This is most unfortunate, as it is useful and easy for routers to "proxify"
> a request by inserting the origin-server IP addr into the URI, and then use
> NAT to redirect an HTTP request to a proxy server (such as squid) any number
> of networking hops away (by changing the pkt ip dest-addr to that of the
> proxy-server).
>
> This is exactly what I was doing. The reason this approach
> was used is because the 'Host' header may not be in the same packet as the
> HTTP URI, and hence the router may not have the hostname information. The
> only other alternative seems to be for the router to peform the more
> expensive and complicated task of proxying the request in order to get the
> entire http header.

What you have done is a nice and simple approach, and nothing stops you
from adding a configuration option to Squid to optionally operate in
this mode (prefer Host header over the URI). Hoewever, it is perhaps
better done outside the HTTP protocol, or at least with an unambigous
marker to make the traffic invalid for a proxy not understanding the
forwarding format.

Other used approaches is to use some tunnelling protocol for the
communication between the router and the cache. I have made a very
simple TCP based protocol with a Squid implementation (see
http://squid.sourceforge.net/hno/patch-old.html, look for TPROXY). More
commonly used options is GRE encapsulation of the forwarded traffic, or
direct routing if on the same segment.
Some wendors also use a out-of-band protocol for communication between
the cache and the "router" where the cache can ask for the real
destination of the redirected TCP connecion.

--
Henrik Nordstrom
Squid hacker