Re: p1: Via and gateways

Amos Jeffries <> Sun, 21 April 2013 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B692621F8771 for <>; Sat, 20 Apr 2013 18:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_45=1, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HeRq5hReT2Vr for <>; Sat, 20 Apr 2013 18:11:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1ED9521F86F2 for <>; Sat, 20 Apr 2013 18:11:55 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UTing-0006fA-85 for; Sun, 21 Apr 2013 01:10:40 +0000
Resent-Date: Sun, 21 Apr 2013 01:10:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UTinc-0006eV-PQ for; Sun, 21 Apr 2013 01:10:36 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1UTinb-0000ll-TG for; Sun, 21 Apr 2013 01:10:36 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 9C66CE6EC1 for <>; Sun, 21 Apr 2013 13:10:12 +1200 (NZST)
Message-ID: <>
Date: Sun, 21 Apr 2013 13:10:12 +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
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=-3.2
X-W3C-Hub-Spam-Report: AWL=-3.162, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UTinb-0000ll-TG 9491b5ce88ae5da71ce484f2b119ab51
Subject: Re: p1: Via and gateways
Archived-At: <>
X-Mailing-List: <> archive/latest/17440
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 

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.