Re: p1: Via and gateways

Via makes sense for proxies that don't act with the authority of either
end-point, and are likely speaking to public-internet IPs on both sides.
There are relatively few of these that would bother to add Via given that
they're likely transparent proxies and increasing packet size is likely a
pain.

A loadbalancer (reverse proxy) wouldn't do Via, because it IS the website,
for all intents and purposes, and what happens behind it (even if it is
just HTTP proxying) is simply part of generating the response as far as the
rest of the world is concerned.
It is unlikely that one would wish to expose the inner workings of one's
private network by exposing this information in a Via (that goes for
proxies that are part of the client's network too...)

So, ++ to what Willy said.
-=R


On Fri, Apr 19, 2013 at 11:23 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Sat, Apr 20, 2013 at 02:07:11PM +1000, Mark Nottingham wrote:
> >
> > p1 Section 2.3 says:
> >
> > > However, an HTTP-to-HTTP gateway that wishes to interoperate with
> third-party HTTP servers must conform to HTTP user agent requirements on
> the gateway's inbound connection and must implement the Connection (Section
> 6.1) and Via (Section 5.7.1) header fields for both connections.
> >
> > This means that accelerators and CDNs MUST generate a Via header on the
> outbound connection. This isn't widely practiced, and I'm not sure it's
> necessary. Comments?
>
> I know no load-balancer which does it anyway. Especially in hosted
> environments where it is desired that the infrastructure is as much
> transparent to the hosted servers as possible.
>
> I must say I never understood the rationale behind Via because for
> incoming traffic we don't care and for outgoing traffic we don't
> want to disclose to the world our inside details.
>
> Another example of a MUST which makes people think that MUSTs are at user
> option I think.
>
> Willy
>
>
>