W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: Fwd: New Version Notification for draft-schwartz-httpbis-connect-tcp-00.txt

From: Ben Schwartz <bemasc@google.com>
Date: Mon, 14 Nov 2022 12:19:32 -0500
Message-ID: <CAHbrMsAXANY5Ooam8b5vcay8uHkpk8UkOcSWRab8bFce5E-Q5g@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Hi Amos,

Thanks for the links to relevant RFCs and clarifying questions.  I've
written some changes to the text with those in mind [1], which you can see
in the editor's copy [2].  (These changes do not alter the proposed
protocol.)

[1]
https://github.com/bemasc/modern-http-proxies/commit/a98c3ee4f04120680660185ecb7977d96ee8ee98
[2]
https://bemasc.github.io/modern-http-proxies/draft-schwartz-httpbis-connect-tcp.html

Some additional comments below.

On Fri, Nov 11, 2022 at 5:48 PM Amos Jeffries <squid3@treenet.co.nz> wrote:
...

>   * I fail to see how virtual hosting on servers is related to proxies
> servicing CONNECT tunnels. They are historically independent orthogonal
> concepts.
>

Yes, traditionally a single origin could only offer a single HTTP proxy
function.  However, with RFC 9298 ("connect-udp"), this is no longer true.
RFC 9298 UDP proxies live on explicit, arbitrary paths, so many distinct
UDP proxy functions can share a single origin.  This draft defines a TCP
proxying arrangement that can share an origin in the same fashion as an RFC
9298 UDP proxy service.

section 4.1 paragraph 2:
> * The non-standard "http-alt" scheme already exists for use as a
> capability URL to request relay of some URI through a forward-proxy. It
> is just rarely implemented and seems unrelated to what your spec is
> aiming to define.
>

I wasn't able to find any documentation for http-alt, so I can't guess
whether it's related.

IMO you would be better off defining use of something like the Alt-Svc
> header for HTTP request messages and using it to extend the standard
> CONNECT method with alternative destinations a proxy could try
> connecting to if the request-target has issues.
>

This would address the concern about offering multiple destination
addresses, but that is not my primary reason for bringing this proposal.
My primary goal is to define a template-controlled TCP proxying function,
similar to RFC 9298, so that multiple distinct TCP forwarding services can
share a single origin.

Received on Monday, 14 November 2022 17:19:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC