extend the HTTP/3 API for WebTransport support #3362
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3362 +/- ##
==========================================
- Coverage 85.58% 85.39% -0.18%
==========================================
Files 135 135
Lines 9872 9906 +34
==========================================
+ Hits 8448 8459 +11
- Misses 1047 1065 +18
- Partials 377 382 +5
Continue to review full report at Codecov.
|
|
@marten-seemann - this is great. My implementation of webtransport in go (which your PR will, and should, replace) does implement all the other stream types including uni streams, so feel free to use any of my code if it's helpful. |
|
Thank you @adriancable! The main reason that it doesn't have unidirectional stream support yet is that I first wanted to get the basic version running. There are no principal blockers. |
| c.logger.Debugf("error handling stream: %s", err) | ||
| } | ||
| c.conn.CloseWithError(quic.ApplicationErrorCode(errorFrameUnexpected), "received HTTP/3 frame on bidirectional stream") | ||
| } |
There was a problem hiding this comment.
Do we need to return here to avoid an infinite loop?
…om a http.Response.Body
marten-seemann
force-pushed
the
webtransport
branch
from
6b78359
to
ff6313f
Compare
Builds on top of #3360. Only provides support for bidirectional streams at the moment.
To support WebTransport, we need to be able to "hijack" a stream after reading a HTTP/3 frame of type 0x41. The WebTransport implementation then takes over the stream and writes on the QUIC stream directly.
We also need to be able to "hijack" the connection: After we receive a WebTransport upgrade request from the client, we establish a WebTransport connection. On this connection, it is possible to open new streams (that's why we need the
http3.StreamCreator).A work-in-progress implementation of WebTransport has been started here: https://github.com/marten-seemann/webtransport-go.
cc @ydnar @adriancable