Re: p1: Via and gateways

Amos Jeffries <squid3@treenet.co.nz> Sat, 20 April 2013 11:47 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 F254821F86F7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 04:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 6MwDFLC0yrWM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 04:47:48 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D6C5C21F86CE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 20 Apr 2013 04:47:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UTWFY-0006DI-CC for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Apr 2013 11:46:36 +0000
Resent-Date: Sat, 20 Apr 2013 11:46:36 +0000
Resent-Message-Id: <E1UTWFY-0006DI-CC@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UTWFT-0006CU-GM for ietf-http-wg@listhub.w3.org; Sat, 20 Apr 2013 11:46:31 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UTWFS-00026R-Cn for ietf-http-wg@w3.org; Sat, 20 Apr 2013 11:46:31 +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 C0784E711D for <ietf-http-wg@w3.org>; Sat, 20 Apr 2013 23:46:05 +1200 (NZST)
Message-ID: <51727FF9.3040303@treenet.co.nz>
Date: Sat, 20 Apr 2013 23:46:01 +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: ietf-http-wg@w3.org
References: <F7810D5C-45A6-4D01-83ED-2A9AB5856813@mnot.net> <20130420062339.GC26517@1wt.eu> <F884F25D-314D-495F-B68A-944527941238@mnot.net> <20130420065105.GF26517@1wt.eu>
In-Reply-To: <20130420065105.GF26517@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=-3.2
X-W3C-Hub-Spam-Report: AWL=-3.162, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UTWFS-00026R-Cn d668351a390d7d7af2f58a1de0a5d5b3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Via and gateways
Archived-At: <http://www.w3.org/mid/51727FF9.3040303@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17424
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 20/04/2013 6:51 p.m., Willy Tarreau wrote:
> On Sat, Apr 20, 2013 at 04:44:30PM +1000, Mark Nottingham wrote:
>> On 20/04/2013, at 4:23 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>>> On Sat, Apr 20, 2013 at 02:07:11PM +1000, Mark Nottingham wrote:
>>>> p1 Section 2.3 says:
>>>>
>>>>> However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers must conform to HTTP user agent requirements on the gateway's inbound connection and must implement the Connection (Section 6.1) and Via (Section 5.7.1) header fields for both connections.
>>>> This means that accelerators and CDNs MUST generate a Via header on the outbound connection. This isn't widely practiced, and I'm not sure it's necessary. Comments?
>>> I know no load-balancer which does it anyway. Especially in hosted
>>> environments where it is desired that the infrastructure is as much
>>> transparent to the hosted servers as possible.
>>>
>>> I must say I never understood the rationale behind Via because for
>>> incoming traffic we don't care and for outgoing traffic we don't
>>> want to disclose to the world our inside details.
>> Yes. It makes sense for proxies, so that the endpoints can discover the
>> capabilities of the whole path. I'm not convinced that applies to gateways,
>> because they're taking the responsibility of the origin server.
> But are client and servers really making use of the Via header to discover
> this ?
>
> My impression is that nowadays proxies tend to build messages looking the
> closest to what they receive and will either mimmick the HTTP version of
> the proxied request, or arrange for the required conversions (eg: chunked-
> encoding to content-length or close).
>
> I think Amos might have some experience on this.

I do indeed.

Not so much capability detection, but path properties detection. The 
important _capabilities_ tend to be the per-hop ones as mentioned and 
I've yet to see anything using it to handle Expect properly.

Property detection is another story entirely...

Squid currently uses Via as the primary tool for detecting forwarding 
loops which can (and still frequently do) ocur at any time, for any 
number for reasons outside of HTTP itself (NAT misconfiguration, absence 
of split-DNS pointing the proxy at itself or a parent as origin, 
misinformed load balancer, intercepting proxy, etc)
In all these cases the request header is the important one and sending 
it from an intermediary to the server regardless of whether the server 
is believed to be another intermediary or an origin is the key part of 
Via usage. I will vote for keeping at least the request Via as a MUST 
send condition and any HTTP intermediary not sending it should be kicked 
for violation and putting its host machine at risk of that nasty DoS thingy.

I've not seen the reply path Via: having much usage to date. But IMHO 
with the growing usage of interception proxies for port 443 both 
directions will grow in importance as a method of signalling that the 
protocol is end-to-end secure (or not). Note that a lot of 
vendor-specific hacks such as Frontend-HTTPS, Forwarded-For, X-Protocol, 
X-HTTPS etc are simply duplicating information which is supposed to be 
relayed in Via protocol-name field.

FYI: we will shortly be building some extra functionality into Squid to 
make use of these signals for added security in HTTPS and long-term I 
intend to ensure that FTP ICY, gopher etc are properly labeled in Via by 
Squid to showcase and demonstrate the proper usage. No idea at this 
point if that latter part will be of any use to clients but you never 
know - some fancy validation mechanism may want to use it.

Amos