Re: Is CONNECT hop-by-hop?

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 19 April 2019 22:09 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 3CBD2120105 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2019 15:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NgfPE4xIik6V for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2019 15:09:17 -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 077461200D7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 19 Apr 2019 15:09:16 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hHbel-0003bT-TT for ietf-http-wg-dist@listhub.w3.org; Fri, 19 Apr 2019 22:06:51 +0000
Resent-Date: Fri, 19 Apr 2019 22:06:51 +0000
Resent-Message-Id: <E1hHbel-0003bT-TT@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hHbek-0003ag-5Y for ietf-http-wg@listhub.w3.org; Fri, 19 Apr 2019 22:06:50 +0000
Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <lucaspardue.24.7@gmail.com>) id 1hHbei-0002hN-VU for ietf-http-wg@w3.org; Fri, 19 Apr 2019 22:06:50 +0000
Received: by mail-vs1-xe30.google.com with SMTP id g127so3478310vsd.6 for <ietf-http-wg@w3.org>; Fri, 19 Apr 2019 15:06:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L04r8izWkhZfgHYXJQV796bZm4q0V4RngKcyVPjvF/g=; b=R0wr8XtVzO4Bkby3DuIEOceDvSmzMHw43IK0rO/5SMb9h5SjwnVc57HmSxmGT1UkfQ k1W5i2E6waJklaJ5kYUqh69PGO269jevTM6gtrzgV7Vo965O+DqgV1v0fsvSWd0Ddyvo VAuKF8dU/rynnTGhooi6RNxL+3mgjArXG/1CBW2LAx7dUAyOfb3SR0TvYXMu1DhTwIxm aMojb+krg9tB5QcEgl1SNtPwWlq3+zD2F2T5hMsBnZVGaZxD5XsJZjKFRFsJesqzCZ1T OA6vux1l+aIOM454MwYocdabBVXJE04bY+Ip3n0eF8T4rgnhMnIy8Bxv7p88xdNfnjJo ON+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L04r8izWkhZfgHYXJQV796bZm4q0V4RngKcyVPjvF/g=; b=fb97RxBtqCFjhtGuDp5t2OihwEGIgyKnQbqUiVYGXxwp09wwFOOQ0+MSH5++HYq5tc K6tCOebx5oL55xGdMI84TyUuCt4ZDuJ51MDU4i4kSd2OSuPEAFE8K4hAIMfVdVZ0gMGV WbJSPwG1ed/+pVQv40S80ehcC8T6TbqtRYb7l11oss2NhrGGV9ZmQ6wjQD5ZZuLm3WQP 64cz+YRw2XLoVe3EaCuZloaCVYZyKVQT1krOIj6hIzYUPCg3G7LIh6tam8NZFhIdzFIb wggeUw7ieS1CQlUxJIlVn1qsKzoP06s2V47l2/fuAIJrD+YUqixdWEJWy+gXzmdEbS1G INCg==
X-Gm-Message-State: APjAAAXr3MbOrDh3puSz6jGFMWBP00gO89ksuwneTwDkGAhH0VRzJDms LrdHZIeUViH0Gn2SgIO/2YSJ/B3D6Jf1bvHoUf6fWA==
X-Google-Smtp-Source: APXvYqxW69iYi0Dpv6WvAVs484OaqZa4tqOWtGlqZpb9OPpJWPPY2nf3vq0I0IB+iLipHm4e17cKhhHDHK03YUSNmvg=
X-Received: by 2002:a67:7ac9:: with SMTP id v192mr3537548vsc.100.1555711587667; Fri, 19 Apr 2019 15:06:27 -0700 (PDT)
MIME-Version: 1.0
References: <40e1b886-1547-1834-f1e9-6bb05c940b1e@measurement-factory.com>
In-Reply-To: <40e1b886-1547-1834-f1e9-6bb05c940b1e@measurement-factory.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 19 Apr 2019 23:06:18 +0100
Message-ID: <CALGR9oacFoeVsK9gtb2aW+aZi6pDJ2xNhFa2U4dquZ7bkS6uTA@mail.gmail.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000008e584e0586e954af"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e30; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-vs1-xe30.google.com
X-W3C-Hub-Spam-Status: No, score=-2.3
X-W3C-Hub-Spam-Report: AWL=1.544, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hHbei-0002hN-VU d8c408406f04a5a540dfeb45bf38e019
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is CONNECT hop-by-hop?
Archived-At: <https://www.w3.org/mid/CALGR9oacFoeVsK9gtb2aW+aZi6pDJ2xNhFa2U4dquZ7bkS6uTA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36544
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,

This is an interesting thread. You raise some questions that I had not
thought of. It seems like a good time to tighten up language.

I think that the "open a TCP connection" view is the most accurate thing
here. And so the final hop, from last proxy to origin will never have a way
to express such "end-to-end" headers. Proxies, in the role of client, that
are configured to use a proxy would use their own user agent and
authentication.

I'd considered the chaining case in HTTP/2 but just taken for granted that
a proxy that has it's own *HTTP proxy* configured would attempt to use it
when opening TCP connections to the indicated authority. This seems like a
reasonable assumption to make for HTTP proxies. I'm sure there might be
other ways a proxy might choose to tunnel, like SOCKS, but that is down to
local configuration.

Note that HTTP/3 also defines CONNECT to behave like RFC 7540. This raises
some challenges for tunnelling HTTP/3, which is one of the driving use
cases in the HiNT I-D [1].

Cheers
Lucas

[1]
https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/



>