Websockets foreseen in HTTP 1.1

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

Crazy. I had no idea that HTTP 1.1 had already defined an upgrade response code:

10.1.2 101 Switching Protocols

The server understands and is willing to comply with the client’s request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

As near as I can tell, the document is from 1999.

I think that is amazing. I only recently heard of an HTTP response that gets upgraded when I was reading about Websockets, and so I thought the whole “upgrade your protocol” thing was totally new. But now I stumbled on this, and it looks like the need to upgrade to new protocols like Websockets was foreseen in 1999.

This is where I first heard of “upgrade from the HTTP protocol“:

To establish a WebSocket connection, the client and server upgrade from the HTTP protocol to the WebSocket protocol during their initial handshake, as shown in the following example:

Example 1—The WebSocket handshake (browser request and server response)

GET /text HTTP/1.1\r\n Upgrade: WebSocket\r\n Connection: Upgrade\r\n Host: www.websocket.org\r\n …\r\n

HTTP/1.1 101 WebSocket Protocol Handshake\r\n Upgrade: WebSocket\r\n Connection: Upgrade\r\n …\r\n

Post external references

  1. 1
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
  2. 2
    http://www.w3.org/Protocols/rfc2616/rfc2616.html
  3. 3
    http://websocket.org/quantum.html
Source