Re: p1: Via and gateways

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.

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 ?

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 ?

Willy

Received on Tuesday, 23 April 2013 06:45:31 UTC