Connection sharing/pooling

[aboba]

The text in Section 14.2.1 lacks clarity on sharing/pooling of HTTP/3 connections:

"Either establish an HTTP/3 connection or reuse an existing HTTP/3 connection to the host specificed by the url, as specified in [WEB-TRANSPORT-HTTP3]."

Does this mean that an HTTP/3 connection created by fetch will be reused if an Http3Transport is constructed to the same host? Or is the text only applicable to reuse of connections constructed by Http3Transport? Is it possible for a QUIC connection previously created by the QuicTransport constructor to the same host to be reused by Http3Transport?

[yutakahirano]

https://fetch.spec.whatwg.org/#connections has some logic about connection, so we need to talk with @annevk.

[annevk]

Thanks for flagging me, I think that the right thing to do would be to integrate with that section in Fetch and given the questions raised in OP that may or may not need some changes to better accommodate your requirements.

(There are some risks with giving pages detailed control over connections as they can use the user agent/OS global limit as communication channel, but I'm not entirely sure if this API would make the status quo worse.)

[aboba]

There is some complexity here that goes beyond what is in Fetch. For example, Http3Transport requires support for HTTP/3 Datagrams, whereas a connection set up to handle a conventional HTTP/3 Request/Response will not. This means that WebTransport cannot necessarily reuse an existing HTTP/3 connection to the same Origin if that connection was not negotiated for use with WebTransport.

[annevk]

And the other way around? In any event, it seems feasible to add conditions as an optional parameter to "obtain a connection" or something equivalent. It seems nice to keep establishing connections somewhat centralized so any security/privacy considerations that end up changing how they are allocated (such as the ongoing state partitioning effort) end up affecting all. (There might still be work to do here when it comes to WebRTC, not sure.)

[aboba]

This issue needs to take into account whether the client has disabled pooling and whether the origin allows pooling.

[aboba]

@jan-ivar Do we still believe that this issue is "ready for PR"? Using Fetch as a model, it wouldn't seem to difficult to come up with a PR, but wanted to check if that is everyone's understanding.

[jan-ivar]

Hmm, looks like I labeled it and assigned it to @yutakahirano at the second TPAC meeting. Unfortunately, I don't recall the reason, and now wish I'd left a comment. We can go back and look at the meeting I suppose. Does anyone else remember?

[aboba]

At the time, pooling didn't seem particularly controversial. Some concerns were subsequently raised at the IETF WebTransport WG interim meeting (e.g. enabling control of pooling in the API as well as on the server). But I think it's still possible to compose a PR although it might take a bit of back and forth before we're ready to merge it.

[yutakahirano]

Sorry for the long silence. I'm planning something like the following:

• Send SETTINGS_ENABLE_WEBTRANSPORT and H3_DATAGRAM SETTINGS when we obtain a connection in the fetch spec.
• Define "webtransport ready" in the WebTransport spec.
  • A connection is webtransport ready if it has received SETTINGS_ENABLE_WEBTRANSPORT and H3_DATAGRAM SETTINGS.

Do they make sense?

[annevk]

I think you also need to pass a parameter to "obtain a connection" to essentially demand a "webtransport ready" connection (in which case you might not have to define it in WebTransport?).

[aboba]

@annevk I am not sure whether a QUIC connection established for use with WebTransport can be reused for HTTP/3 Request/Response. While negotiating support for HTTP/3 datagrams would not preclude this, HTTP/3 Request/Response and WebTransport would need to cooperate in allocation and use of stream IDs. IMHO, it would be good to figure out if this is possible and if not, whether changes to the HTTP/3 specification could make it possible.

@yutakahirano I think we need to add an (optional) WebTransport constructor argument to disable pooling. Also, an internal slot that indicates whether a WebTransport connection once established supports pooling. At the January 2021 WEBTRANS WG interim, it was agreed that a server supporting WebTransport could refuse to support pooling, in which case the internal slot would indicate that the connection could not be pooled. At present, I believe that support for HTTP/3 Datagrams is required for successful negotiation of a WebTransport connection.