Hi Klaus, Thanks for your email. I think the general answer to your questions is that UDP proxying over HTTP/3 is being specified in the MASQUE WG [1], and that is an appropriate venue for further discussion so I've CC'd them.
I've attempted to reply to specific points in line, speaking as an individual in all of them. On Tue, Jun 7, 2022 at 7:13 PM Klaus Frank <[email protected]> wrote: > Hi, > > I've read the proposed standard RFC 9114 and I think section 4.4 has > some ambiguities. > > 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. > In a nutshell, the CONNECT method changes the usage of an individual request stream. This can be a surprise to those familiar with CONNECT over HTTP/1.1, which takes over the whole connection. HTTP/3 proxies that accept CONNECT will attempt to open a TCP connection to the indicated target server, as defined. The client and proxy talk HTTP/3, the client and target server talk whatever TCP based protocol they like, over the tunnel. The MASQUE WG is defining an equivalent capability for tunneling UDP over HTTP using extended connect. This can work over HTTP/1.1, HTTP/2 or HTTP/3. See draft-ietf-masque-connect-udp [2]. A client that wants to talk HTTP/3, via an HTTP proxy, can use this design to create an end-to-end flow of datagrams that are used to carry the QUIC connection between client and target server. 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), ... > Proxy discovery or application configuration is outside the scope of HTTP specifications. There are many options and different approaches taken depending on user agent software. But there is nothing that HTTP/3 should say about this, in order to be consistent with other documents. 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". > Related to question 1. The specs aren't particularly great at describing these things for the new reader. Me and Chris Wood made a pair of blog post to try and illustrate things, that might help you: [3] [4] > 4. Are HTTP(S) CONNECT proxies now no longer supported with HTTP/3? > You can CONNECT over HTTP/3, so the protocol supports them. Whether client's implement this feature is a different question. Given HTTP/3 is relatively fresh, I'd guess there aren't many clients that generically support this. 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)? > Per draft-ietf-masque-connect-udp, it's possible for the protocol to support UDP tunneling over HTTP/1.1 or HTTP/2. Hence, a client->server HTTP/3 connection via a proxy is possible. Whether that gets implemented widely is another open question and something the IETF can't really answer. 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? > I'm not sure I follow this question. This form of HTTP proxy is restricted to opening a TCP connection (or a UDP socket, with draft-ietf-masque-connect-udp) to a target server and forwarding the traffic back and forth. Once one is established, it is expected that the client initiates a secure end-to-end connection. The proxy cannot modify this secure connection because it does not have access to the keys. > It would be great if these points could be addresses within the standard > just do avoid confusion. > HTTP/3 is consistent with the HTTP semantics and HTTP/2 specs and given the work happening in MASQUE. Within the scope that protocol documents operate, I think HTTP/3 is complete and no changes are necessary. > Sincerely, > Klaus Frank > > Cheers, Lucas [1] - https://datatracker.ietf.org/wg/masque/about/ [2] - https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/ [3] - https://blog.cloudflare.com/a-primer-on-proxies/ [4] - https://blog.cloudflare.com/unlocking-quic-proxying-potential/
