- From: Ben Schwartz <bemasc@google.com>
- Date: Mon, 14 Nov 2022 12:19:32 -0500
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CAHbrMsAXANY5Ooam8b5vcay8uHkpk8UkOcSWRab8bFce5E-Q5g@mail.gmail.com>
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.
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 14 November 2022 17:19:58 UTC