- 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