Re: p1: Via and gateways

Willy Tarreau <w@1wt.eu> Wed, 24 April 2013 06:39 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 2B44321F85EB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 23:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.239
X-Spam-Level:
X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, 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 LwxMx5VZjovg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 23:39:14 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4621F85E8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 23:39:13 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUtLk-000751-Qy for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 06:38:40 +0000
Resent-Date: Wed, 24 Apr 2013 06:38:40 +0000
Resent-Message-Id: <E1UUtLk-000751-Qy@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UUtLh-00072k-2i for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 06:38:37 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UUtLg-0004LS-4n for ietf-http-wg@w3.org; Wed, 24 Apr 2013 06:38:37 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3O6cAiX018821; Wed, 24 Apr 2013 08:38:10 +0200
Date: Wed, 24 Apr 2013 08:38:10 +0200
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20130424063810.GG15918@1wt.eu>
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> <74FF747A-D93A-436D-ACFB-F72BFFBBA2A4@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <74FF747A-D93A-436D-ACFB-F72BFFBBA2A4@mnot.net>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-0.0
X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UUtLg-0004LS-4n f7d2aad3eb0d7fcb55e5b72697757c27
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Via and gateways
Archived-At: <http://www.w3.org/mid/20130424063810.GG15918@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17527
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 Wed, Apr 24, 2013 at 01:27:45PM +1000, Mark Nottingham wrote:
> 
> On 23/04/2013, at 4:43 PM, Willy Tarreau <w@1wt.eu> wrote:
> 
> > 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.
> 
> This is already covered further down:
> 
> > A proxy or gateway may combine an ordered subsequence of Via header field
> > entries into a single such entry if the entries have identical
> > received-protocol values.

I don't read it exactly the same way, but probably it achieves the same in
the end.

> The question I was raising was specific: can we relax the requirement for a
> gateway to add Via to responses if there isn't already one present?

I think yes, we can relax it, as if there was none, then it means the
gateway has not changed the connection's behaviour and the next hop just
assumes the connection comes from the client. Again, in my understanding,
Via is used to understand what transformation was operated on the path
and what capabilities are offered. If the gateway does not change anything,
Via offers no value except detecting loops. And since most gateways simply
forward to the configured next hop, the risk of loop is not caused by
external environment (eg: DNS) but by the configuration so it's not a
problem.

But if we do so, we must specify that a gateway MUST NOT remove the
Via header field in any case, otherwise it will break the loop detection
mechanism of some other components.

Regards,
Willy