HTTP/3 (Proposed RFC 9114) and HTTP CONNECT ambiguities

[Klaus Frank]

Hi,




1. This section says "It is primarily used with HTTP proxies to
   establish a TLS session with an origin server for the purposes of
   interacting with 'https' resources", but further down it says "A
   proxy that supports CONNECT establishes a *TCP* connection". This
   section needs to be updated to include UDP+QUIC for HTTP/3 in some
   way. Otherwise HTTP CONNECT to HTTP/3 endpoint won't be possible.
2. It doesn't mention how a HTTP CONNECT proxy that uses HTTPS works
   within HTTP/3 (how does the server part of "export
   all_proxy=https://myproxy.example.com"; look like?), use cases for
   this currently are: VPN replacement, authenticated proxies (like at
   universities) to access web resources like scientific journals from
   outside of the university network, to encrypt the SNI header of
   requests between a client and the proxy, to have an authenticated
   connection to a proxy to do endpoint filtering to harden internal
   networks while (while having the proxy remote and not on the same
   local network, therefore encrypting traffic), ...
3. This section also says "In HTTP/2 and HTTP/3, the CONNECT method is
   used to establish a tunnel over a single stream.", which when I
   assume it means to bundle multiple requests into a single QUIC
   stream, would not work as it further down mandates the use of TCP "A
   proxy that supports CONNECT establishes a TCP connection".
4. Are HTTP(S) CONNECT proxies now no longer supported with HTTP/3?
5. Can a HTTP/1.1 or HTTP/2 HTTP(S) CONNECT proxy sit in between a
   client and a HTTP/3 server (downgrading the connection)?
6. (half off topic) Would a HTTP/2 HTTP(S) CONNECT proxy that allows
   connecting to HTTP/3 servers over QUIC instead of TCP be still
   compliant to the former RFC, or would implementing forward
   compatibility with HTTP/3 in the proxy (by internally silently
   establishing a UDP+QUIC connection to the requested resource instead
   of a TCP one like specified) make the implementation non compliant
   with the RFC?



Sincerely,
Klaus Frank

I've read the proposed standard RFC 9114 and I think section 4.4 has some ambiguities. It would be great if these points could be addresses within the standard just do avoid confusion.

smime.p7s
Description: S/MIME Cryptographic Signature