Re: p1: Via and gateways

On 20/04/2013 6:51 p.m., Willy Tarreau wrote:
> On Sat, Apr 20, 2013 at 04:44:30PM +1000, Mark Nottingham wrote:
>> On 20/04/2013, at 4: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.
>> Yes. It makes sense for proxies, so that the endpoints can discover the
>> capabilities of the whole path. I'm not convinced that applies to gateways,
>> because they're taking the responsibility of the origin server.
> But are client and servers really making use of the Via header to discover
> this ?
>
> My impression is that nowadays proxies tend to build messages looking the
> closest to what they receive and will either mimmick the HTTP version of
> the proxied request, or arrange for the required conversions (eg: chunked-
> encoding to content-length or close).
>
> I think Amos might have some experience on this.

I do indeed.

Not so much capability detection, but path properties detection. The 
important _capabilities_ tend to be the per-hop ones as mentioned and 
I've yet to see anything using it to handle Expect properly.

Property detection is another story entirely...

Squid currently uses Via as the primary tool for detecting forwarding 
loops which can (and still frequently do) ocur at any time, for any 
number for reasons outside of HTTP itself (NAT misconfiguration, absence 
of split-DNS pointing the proxy at itself or a parent as origin, 
misinformed load balancer, intercepting proxy, etc)
In all these cases the request header is the important one and sending 
it from an intermediary to the server regardless of whether the server 
is believed to be another intermediary or an origin is the key part of 
Via usage. I will vote for keeping at least the request Via as a MUST 
send condition and any HTTP intermediary not sending it should be kicked 
for violation and putting its host machine at risk of that nasty DoS thingy.

I've not seen the reply path Via: having much usage to date. But IMHO 
with the growing usage of interception proxies for port 443 both 
directions will grow in importance as a method of signalling that the 
protocol is end-to-end secure (or not). Note that a lot of 
vendor-specific hacks such as Frontend-HTTPS, Forwarded-For, X-Protocol, 
X-HTTPS etc are simply duplicating information which is supposed to be 
relayed in Via protocol-name field.

FYI: we will shortly be building some extra functionality into Squid to 
make use of these signals for added security in HTTPS and long-term I 
intend to ensure that FTP ICY, gopher etc are properly labeled in Via by 
Squid to showcase and demonstrate the proper usage. No idea at this 
point if that latter part will be of any use to clients but you never 
know - some fancy validation mechanism may want to use it.

Amos

Received on Saturday, 20 April 2013 11:46:31 UTC