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

Section 1.1 paragraph 2:
"
  HTTP/3 uses a UDP transport, so the pre-existing CONNECT mechanism was 
not applicable.
"

The CONNECT method is still supported by HTTP/3 and has the same meaning 
per RFC 9114 section 4.4 (and RFC 9113 section 8.5 before it).
All that has changed is how the TCP packet payloads are exchanged with 
the client as HTTP DATA frames.


Section 1.2 paragraph 1:
"
Classic HTTP CONNECT proxies are identified by an origin, not a URI. The 
proxy service does not have a path of its own. This prevents any origin 
from hosting multiple distinct proxy services and makes it difficult to 
manage a proxy service in a fashion similar to other HTTP services.
"

What is this supposed to be saying?

  * an authority-uri definitely is an URI.

  * the use of "proxies" and "proxy" words do not make any sense here.

  * managing proxy services has nothing to do with relaying/proxying 
CONNECT tunnels

  * how exactly is running multiple proxy services related to how each 
of them interprets a CONNECT request method?


Section 1.2 paragraph 2:
"
    In HTTP/1.1, the "Host" header enables such
    virtual-hosting by distinguishing the hostname of the proxy (in the 
Host header) from the hostname of the destination (in the request target).
"

This is incorrect. RFC 9112 section 3.2 forbids Host header value 
differing from the request-target authority value:
"
If the target URI includes an authority component, then a client MUST 
send a field value for Host that is identical to that authority component
"


Section 3.1:
"
   If a TCP connection was not established, the proxy MUST NOT return a 
101 or 2XX status code.
"

This is a direct conflict with RFC9110 restrictions on Upgrade header:
"
   A server MAY ignore a received Upgrade header field if it wishes to 
continue using the current protocol on that connection.
   Upgrade cannot be used to insist on a protocol change
"


section 4.1 paragraph 1:
  * I fail to see how virtual hosting on servers is related to proxies 
servicing CONNECT tunnels. They are historically independent orthogonal 
concepts.

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.


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.


Cheers
Amos

Received on Friday, 11 November 2022 22:44:56 UTC