Re: p1: Via and gateways

Amos Jeffries <> Tue, 23 April 2013 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E102B21F96A0 for <>; Tue, 23 Apr 2013 06:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.749
X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_BACKHAIR_45=1, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jua2nuIq774t for <>; Tue, 23 Apr 2013 06:10:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 006FC21F969D for <>; Tue, 23 Apr 2013 06:10:20 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UUcxr-0001jr-Gh for; Tue, 23 Apr 2013 13:08:55 +0000
Resent-Date: Tue, 23 Apr 2013 13:08:55 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUcxj-0001j3-7Q for; Tue, 23 Apr 2013 13:08:47 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1UUcxh-0000hw-G9 for; Tue, 23 Apr 2013 13:08:47 +0000
Received: from [] ( []) by (Postfix) with ESMTP id E5B02E6F39; Wed, 24 Apr 2013 01:08:17 +1200 (NZST)
Message-ID: <>
Date: Wed, 24 Apr 2013 01:08:14 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Willy Tarreau <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.499, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UUcxh-0000hw-G9 0d815d26c141be3993c739acbcc96d95
Subject: Re: p1: Via and gateways
Archived-At: <>
X-Mailing-List: <> archive/latest/17498
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> 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.