CONNECT and tunnel support

[stevenctl]

From the proposal:

HTTP CONNECT to tunnel over a single QUIC stream

Curious what the status is? If nobody is working on this I'd be happy to contribute although I might need a bit of guidance.

Guidance mostly around the expected API surface. Currently inspecting h2 as a reference.

If the proxy
detects that the client has reset the stream or aborted reading from
the stream, it MUST close the TCP connection.

The client TCP connection and probably server TCP connection would be managed by the application/proxy that depends on h3 (at least for the usecases I have in mind). Is there desire to handle that forwarding in h3? I assume not.

[nmittler]

Gentle ping ... any feedback from a maintainer would be great.

[seanmonstar]

I don't know what the status is. Does it not "just work" right now?

Anything in the spec we likely want to support. If you want to try to figure out what is needed, you're welcome to! I don't know if any of the others have the time to focus on this, though.

[nmittler]

@seanmonstar ah got it. I think we were just assuming there were missing pieces since it was still listed in the roadmap

[seanmonstar]

It certainly could be, I haven't checked at all. I've already forgotten what even is required. If it's similar to HTTP/2 CONNECT, then we probably need some work done.

[Eveeifyeve]

HTTP/2 CONNECT

Just from reading https://datatracker.ietf.org/doc/html/rfc9114#section-4.4 it seems to be a lot of changes to how it works but most of it stays the same.

[yaroslavros]

#322 brings client behaviour inline with requirements of standard CONNECT for TCP tunnelling.