3 ms·
The kicker is if a client connects to you via HTTP/2, you can't upgrade/hijack that session to be a websocket stream since the underlying TCP connection could b
by voidlogic 8y ago
The kicker is if a client connects to you via HTTP/2, you can't upgrade/hijack that session to be a websocket stream since the underlying TCP connection could be being shared by(used to multiplex) multiple HTTP requests/sessions. You have to take care to make sure the request ingress path from the client to the app is HTTP/1.1 end to end. That is something that is getting harder to do. Browsers use H/2 by default, more and more CDN do, more and more middle-ware does etc. The draft RFC I mentioned is a websocket upgrade mechanism for HTTP/2.
- Matthias247 8y agoI don't see an issue. If a browser wants to create a websocket connection, it will always create a fresh connection and do a HTTP/1.1 upgrade. Because that's the only way how websockets are specified. On the server side most things are handled in the low-level HTTP handlers. There (e.g. in Netty/Jetty and Co) one needs to care about ALPN negotiation, websocket upgrades and Co. But higher up (J2EE, express, etc) things are mostly about HTTP semantics, and there isn't any handling about "upgrade" or even the "Connection" field in general anymore. Yes, the line between HTTP application semantics and HTTP/1.1 transport is very thing and nobody exactly knows where things start and end. But I'm still not convinced we need web sockets over HTTP/2, e.g. in order to allow upgrades in the application layer.