Introduce "connection pool" and a concept of a "connection"

[igrigorik]

Chrome and Firefox now support <link rel=preconnect>, which performs the dns/tcp/tls handshakes with the specified origin. However, today there is no way to perform this operation from a Worker - e.g. my SW wants to initiate a preconnect in anticipation of an upcoming request.

Can we express this via Fetch? Should it be a separate API?

Parent bug: w3c/resource-hints#36

[annevk]

I think it needs to be a separate API since what it seems to be doing is essentially establishing a connection of sorts. Whereas Fetch might grab such a connection if it exists, or establish a new one otherwise. And even that is not really Fetch' purview, that is more HTTP which takes care of that. And WebSocket presumably has something similar.

You should probably first have a clear processing model for what preconnect is supposed to be doing. Then you could build an API on top.

[igrigorik]

Yep, makes sense. Yay to more platform archeology... :)

[annevk]

It might actually make sense to define this new preconnect concept in Fetch given @sleevi's feedback there.

[annevk]

w3c/resource-hints#34 (comment) explains what we want to do here.

[annevk]

Okay, so basically we want to split making a request into obtaining a connection and then making a request over that connection.

Connections are "stored" in a user-agent-wide connection pool. They are keyed on request's url's origin and credentials flag.

Obtaining a connection tries to get one out of the connection pool, and if there is none, establishes one in a manner that is mostly up to the user agent (for the time being anyway).

rel=preconnect could then basically be defined as trying to obtain a connection if the user agent considers it a good idea.

@sleevi @igrigorik?

[igrigorik]

@annevk sounds like we'd define "connection pool" as a term but won't get into specifics of how its managed, etc -- correct? For keying, I think we also need the "negotiated protocol" bit in there.

Overall though, sounds reasonable.

[annevk]

Yeah, connection pool is just an indication of there being a cache/store of sorts. Where would the negotiated protocol come from? Isn't that established when you actually make a connection? How would you have access to that when looking up connections in the pool?

[igrigorik]

I was thinking websocket vs http, but I guess that's a whole separate discussion (Fetch does not "explain" websockets, correct?). For things like http/1.1 vs http/2 the pool would implement own smarts to determine if a connection can be re-used; no need to key on that.

[annevk]

WebSocket vs Fetch is tracked in whatwg/html#180. I actually think WebSocket does sit on top of Fetch in browsers in practice, but specifying it that way will require forking the IETF protocol specification a bit...

Anyway, I think I will ignore WebSocket here for now and we can address that separately. It does seem to me WebSocket should be able to reuse these connections.

[igrigorik]

Sounds good.

[sleevi]

Yeah, things get messy when you consider H/2 pooling (cross-origin), and also multi-profile (I read "User-agent-wide" to be ambiguous)

That said, that's extreme spec pedantry, and I think other than those pedantic nits which don't meaningfully alter things, yes, that sounds like the right idea.

re: WebSockets: The story on Chrome is complex, and the code itself is quite difficult to read. It's "supposed" to be that WebSocket connections can re-use connections from the underlying pools (e.g. the TCP pool that feeds into the TLS pool that is then used for WSS), but that those connections don't count against things like connection limits (since part of the point of WS[S] was to avoid HTTP/1.1 connection limits). AIUI, if we try a WS handshake and it fails to go through the Upgrade path, we'll still let that HTTP/1.1 connection hang out in the pool if it was Keep-Alive. But if they completed the Upgrade, they'll never re-enter the pool. But honestly, I can't give you a clear answer about what is supposed to happen or what will happen, so deferring that sounds good :)

[annevk]

I didn't fix OP. We might still want to add a preconnect() API of sorts I suppose, but it doesn't matter much where that is defined. If Fetch should define that I'll open a new issue.