Re: p1: Via and gateways

Amos Jeffries <squid3@treenet.co.nz> Tue, 23 April 2013 13:10 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E102B21F96A0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 06:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.749
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jua2nuIq774t for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 06:10:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 006FC21F969D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 06:10:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUcxr-0001jr-Gh for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 13:08:55 +0000
Resent-Date: Tue, 23 Apr 2013 13:08:55 +0000
Resent-Message-Id: <E1UUcxr-0001jr-Gh@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UUcxj-0001j3-7Q for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 13:08:47 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UUcxh-0000hw-G9 for ietf-http-wg@w3.org; Tue, 23 Apr 2013 13:08:47 +0000
Received: from [192.168.2.7] (103-9-43-128.flip.co.nz [103.9.43.128]) by treenet.co.nz (Postfix) with ESMTP id E5B02E6F39; Wed, 24 Apr 2013 01:08:17 +1200 (NZST)
Message-ID: <517687BE.9060900@treenet.co.nz>
Date: Wed, 24 Apr 2013 01:08:14 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
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 <w@1wt.eu>
CC: ietf-http-wg@w3.org
References: <F7810D5C-45A6-4D01-83ED-2A9AB5856813@mnot.net> <alpine.LRH.2.01.1304200017490.18732@egate.xpasc.com> <37AD85F8-D0E1-4B9D-9BF0-99EBE83ADF8D@mnot.net> <20130420080919.GP26517@1wt.eu> <51733C74.9050701@treenet.co.nz> <20130423064325.GC8496@1wt.eu>
In-Reply-To: <20130423064325.GC8496@1wt.eu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
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: maggie.w3.org 1UUcxh-0000hw-G9 0d815d26c141be3993c739acbcc96d95
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Via and gateways
Archived-At: <http://www.w3.org/mid/517687BE.9060900@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17498
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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 <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