Re: p1: Via and gateways

On 20/04/2013 8:09 p.m., Willy Tarreau wrote:
> On Sat, Apr 20, 2013 at 05:55:59PM +1000, Mark Nottingham wrote:
>> On 20/04/2013, at 5:21 PM, David Morris <dwm@xpasc.com> wrote:
>>> I don't care about MUST, but I think the Via header can be useful for
>>> problem determination. A smart content server could also adjust for
>>> a detected accelerator and/or transcoder ... perhaps by avoiding
>>> optimizations dependant on a direct connection and byte/byte transfer
>>> between the client and the server.
>>>
>>> So I'm very much in favor of keeping the Via: header.
>>
>> Definitely not talking about getting rid of it. The (only, specific) point
>> here is whether a gateway that doesn't add Via to responses should be called
>> non-conformant.
>>
>> Personally, I think it should be a MUST for proxies, in both directions.
>> However, for a gateway, it either shouldn't be a requirement at all (for
>> responses), or it should be a SHOULD with a get-out clause for reasons of
>> security (along with a note that they'll need to accept responsibility for
>> any issues caused by omitting Via). Still should probable be a MUST for
>> requests from gateways.
> But then do we want to declare all gateways non-conformant ? The only gateway
> I've seen use the Via header was abusing it to put the client's IP address
> into it, and none of the hosted servers behind it were ever confused by this
> despite being a few tens of various products!
>
> The only use I see with Via is to convey the original message's HTTP version,
> but most (all?) gateways do not change this version because it's already
> painful to be a gateway, you generally don't want to add more burden by
> changing the protocol version between the two sides!

IMO, that is behaviour compliant with the Via semantics in the last 
paragraph(s) of section 5.7.1 of the latest drafts text. A series of 
labels can be compacted down to one label if they are all conveying the 
same version information. A load balancer, SOCKS gateways, magic devices 
only have to ensure they are accurately preserving the traffic behaviour 
used by their sources at each end in order to be compliant under that 
loophole.

The ones I've seen doing HTTP<->HTTPS translation have largely been 
adding some form of "X-HTTPS: on" header anyways, so asking them to use 
the Via as standard mechanism instead would seem not to be a burden.

Section 5.7.1 are a little obtuse and hide this case a bit. So that 
section could perhapse be clarified to explain that hops preserving the 
protocol semantics are not obliged to *add* to Via (although they are 
still required to relay any existing one).

However, all said and done I'm for retaining the sentence in p1 section 
2.3 as-is.

Amos

Received on Sunday, 21 April 2013 01:10:36 UTC