WebSocket connections need partitioning

[annevk]

Currently WebSocket connections share no infrastructure with "HTTP" connections, this is somewhat wrong, at least when it comes to state partitioning.

(See also #1118.)

cc @MattMenke2 @shivanigithub @sleevi

[MattMenke2]

In Chromium, we've already wired up partitioning to WebSockets (though are not yet shipping it), so we certainly agree with this.

[annevk]

As WebSocket connections are dedicated connections, partitioning isn't strictly needed. #1241 will further clarify this. That will also make them have a partitioning key, though it will not end up mattering.

I think that means this can be closed.

[MattMenke2]

While they're not covered in the fetch spec, there are other caches (TLS session resumption), websocket over shared H2/QUIC connections, ALPN data, and the DNS cache, that are partitioned, and WebSockets should presumably pull all of those from the correct partition. If proxy connections and the HTTP auth cache are partitioned, needs to use the right partition for those as well.

[annevk]

Ideally we would cover those in Fetch I think (or at least mention that they should be considered part of the connection and thus be partitioned).

If WebSocket over H2 (and QUIC? Is there an RFC for that?) can reuse a connection, Fetch needs some more complicated logic than I suggested in #1241. Not immediately clear to me what that would look like. forceDedicatedIfH1 or some such...

[MattMenke2]

Unfortunately, I'm not familiar enough with WebSockets or H2/H3 to know where the details are specified.

[annevk]

There's https://datatracker.ietf.org/doc/html/rfc8441 for H2.

[ricea]

WebSocket over H2 does reuse connections. Currently you can't use WS/H2 at all unless you have an existing H2 connection.

WebSocket over H3 is not a thing yet although in principle it should be a straightforward application of WS/H2 semantics.

[annevk]

Thanks everyone. I'm going to fold this into #1243 as that will truly solve this (fingers crossed).