Re: p1: Via and gateways

On 23/04/2013 6:43 p.m., Willy Tarreau wrote:
> Hi Amos,
>
> On Sun, Apr 21, 2013 at 01:10:12PM +1200, Amos Jeffries wrote:
>> 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).
> I think that could make sense, especially with the loop detection you
> explained in your other mail. It's true that proxies are clearly at
> risk of looping due to external misconfigurations and I understand
> why it makes sense to use it in your case. So I believe that what makes
> a different use case of it is the sensibility of the component to its
> environment. For example, a proxy such as Squid will rely on the
> correspondance between the Host header field and the DNS configuration
> so it's totally at risk of looping. A reverse-proxy such as a load
> balancer will just use its own static configuration and is not exposed
> to this case.
>
> So when someone deploys haproxy in front of squid, it's OK if haproxy
> does not add Via as long as it does not remove it.

And so long as the HTTP version is the same yes.

> I know that Roberto has a good point of view about reverse proxies, he
> regularly says that they can be seen as part of the server (in that they
> are totally useless alone). I think it probably is the correct way of
> describing it, as in the example above, the haproxy+squid example can
> be seen as a larger proxy and the Via header field is still added by
> this "component".
>
>> However, all said and done I'm for retaining the sentence in p1 section
>> 2.3 as-is.
> That said, Mark's initial question is still valid. Considering that many
> existing components don't add it anyway, do we really need to declare them
> non-compliant ?

IMO, for most no, for some which are changing the version and thus 
expected semantics yes and it would be a Good Thing to do so in those cases.

> I'm now thinking that maybe the goal of this Via header field needs to be
> described prior to saying what must be done with it, so the two first
> sentences should be swapped :
>
> 5.7.1 Via
>     The "Via" header field is used in HTTP for tracking message forwards,
>     avoiding request loops, and identifying the protocol capabilities of
>     all senders along the request/response chain. The "Via" header field
>     MUST be sent by a proxy or gateway in forwarded messages to indicate
>     the intermediate protocols and recipients between the user agent and
>     the server on requests, and between the origin server and the client
>     on responses.
>
> Then I would propose this addition :
>
>     Multiple Via field values represent each proxy or gateway that has
>     forwarded the message.  Each recipient MUST append its information
>     such that the end result is ordered according to the sequence of
> -  forwarding applications.
> +  forwarding applications. A gateway MAY simply relay any existing Via
> +  header field if it does not change the HTTP version, but it MUST NOT
> +  remove it.
>
> What do you think ?

Sounds good to me.

Amos

Received on Tuesday, 23 April 2013 13:08:47 UTC