Re: Is CONNECT hop-by-hop?

Willy Tarreau <w@1wt.eu> Sat, 20 April 2019 05:56 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 C1A6F12009A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2019 22:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEgGXghmexIM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2019 22:56:49 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6FE12000E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 19 Apr 2019 22:56:49 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hHix9-0008EL-Bv for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Apr 2019 05:54:19 +0000
Resent-Date: Sat, 20 Apr 2019 05:54:19 +0000
Resent-Message-Id: <E1hHix9-0008EL-Bv@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <w@1wt.eu>) id 1hHix7-0008DX-01 for ietf-http-wg@listhub.w3.org; Sat, 20 Apr 2019 05:54:17 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.89) (envelope-from <w@1wt.eu>) id 1hHix5-0006i8-70 for ietf-http-wg@w3.org; Sat, 20 Apr 2019 05:54:16 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x3K5rn9P002389; Sat, 20 Apr 2019 07:53:49 +0200
Date: Sat, 20 Apr 2019 07:53:49 +0200
From: Willy Tarreau <w@1wt.eu>
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20190420055349.GB2369@1wt.eu>
References: <40e1b886-1547-1834-f1e9-6bb05c940b1e@measurement-factory.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <40e1b886-1547-1834-f1e9-6bb05c940b1e@measurement-factory.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-0.416, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hHix5-0006i8-70 5c6e34fd2daab5fbe471186205cc8107
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is CONNECT hop-by-hop?
Archived-At: <https://www.w3.org/mid/20190420055349.GB2369@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36546
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Alex,

On Fri, Apr 19, 2019 at 02:20:30PM -0600, Alex Rousskov wrote:
> The correct answer probably depends on whether the CONNECT is a
> hop-by-hop mechanism. Mozilla got it right if the CONNECT request is
> meant specifically for the proxy at the next hop. HTTP/1 got it right if
> CONNECT is meant for all proxies in the chain.
> 
> Should a compliant HTTP proxy forward regular end-to-end CONNECT headers
> to the next proxy?

I have a different view on this. In my opinion CONNECT is indeed hop by
hop, but if it ends on proxy which itself is configured to use another
forward proxy instead of connecting directly to the net, then this second
proxy will likely emit another CONNECT request to that proxy. Of course
both requests might end up being the same, but if you look at authentication
headers, the ones from the first request are there to authenticate on the
first proxy. The second proxy might need a hard-coded authentication in
order to pass through the second proxy, and will likely use its own auth
headers, unless it is configured to pass credentials verbatim.

I find that it's easier to see it as a demand by the client to establish
a clear data path to the TCP endpoint mentioned in the authority. The
client doesn't care how intermediaries split the work, if they use other
CONNECT between them, if one relies on SOCKS, or even use RFC1149, provided
the last element in the chain reaches this endpoint.

Regards,
Willy