Finding an Abstraction for HTTP Upgrade

Most of the time, HTTP interactions take the form of a request followed by response, which maps well to a function call and its return value. But, when it comes to also being able to handle protocol upgrades, that abstraction immediately breaks down.

In HTTP/1.1, a client may request an “upgrade” by sending headers Connection: Upgrade and Upgrade: websocket, for example. The server can then respond with status 101 Switching Protocols along with any relevant headers. That would conclude the HTTP interaction. Further communication happens on the same connection but with the other protocol.

Protocol upgrades are weird because the client and server start out communicating using HTTP and then abruptly switch to a different protocol. In contrast, when communicating over TLS, the client and server start by negotiating which protocol to use via ALPN.

An ideal workflow to abstract over would consist of two independent steps: protocol negotiation followed by data transfer. That way, separate abstractions can be made for the two steps as opposed to a single, more complex abstraction that handles everything.

I did some searching for protocols that actually use the “Upgrade” header. The only one I could find is WebSocket. There are references to upgrading from unencrypted HTTP/1.1 to unencrypted HTTP/2 but I don’t think that’s implemented anywhere; after all, no browsers even support unencrypted HTTP/2.

So, a more practical abstraction would hide HTTP upgrade semantics and handle all possible upgrades internally, exposing normal HTTP request-response and WebSocket interactions.