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

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


Some additional comments below.

On Fri, Nov 11, 2022 at 5:48 PM Amos Jeffries <> 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