Repository navigation
quic: http/3 getting server settings and customSettings #63362
Description
For applications such as webtransport, http settings are important for negotiating capabilities.
The following problems may be present currently:
1.) I do not see a clear API path for a client that connects to a server to get the settings sent by the server.
Looking at the C++ code, I think the available settings could be on the SessionTicket,
However, if I immediately set a callback to onsessionticket after the Promise for QuicSession is fulfilled, I do not see a call.
@jasnell : Is there another API path to get this information? Or is this a bug, if I do not see the callback? Then I will try to make a test.
2.) nghttp3 does not seem to support settings beyond the settings hardcoded in the library. I will query upstream about implementing a mechanism similar to the customSettings mechanism currently used for http2.
Activity
jasnell commentedon May 16, 2026
I've been following @tatsuhiro-t's work on webtransport support and plan to update when it's ready. I intentionally have not provided an api to directly expose the settings yet as it wasn't clear (at the time) how things would shape up. Can definitely look at doing so now
martenrichter commentedon May 16, 2026
Then we wait until the RFC is out, which is the trigger for @tatsuhiro-t to release.
I have just read to day the spec a bit more in detail, also @tatsuhiro-t said that nghttp3 needed a patch for bidi streams.
I do not understand so far why, but I assume he is right.
So I will proceed porting it, but I will then work with a patched quiche counterpart, where I deactivate checks, that we can not currently implement. In this way I can see, what problems with the underlying stream are and we are prepared for the real implementation. Testing against the browsers will not work.
(Would there be a way to have an experimental node.js branch on top of the nghttp3 PR for webtransport?)
martenrichter commentedon May 16, 2026
Ok, some progress, I have patched quiche so that it assumes that there is always webtransport support.
I will document, what to do later.
It sort of connects, and then something crashes, I have to investigate, who is responsible. (I can't tell more).
martenrichter commentedon May 23, 2026
Ok, I got a connection, but then it was closed as the http3 implementation in ngtcp2 does not allow to receive new stream from server.
I could reimplement some basic http/3 logic on quic for testing, or I try to build in the ngtcp3 patch into the node.js build.
martenrichter commentedon May 23, 2026
Backport of the upstream nghttp3 webtransport PR (ngtcp2/nghttp3#442):
https://github.com/martenrichter/node/tree/nghttp3-webtransport-backport
martenrichter commentedon May 24, 2026
I am playing around with implementing native webtransport support.
Main purpose is that I can use my tests, but it may be also useful otherwise?
https://github.com/martenrichter/node/tree/webtransportinterfaces
Any use if I would do a draft PR.....