[whatwg] Content encoding (e.g. compression) in Web Sockets

[Doug Simpkinson]

The current Web Socket wire protocol does not make allowances for
compression.  In cases where only small messages are passed this is
not a concern, but if larger messages are to be passed then
compression is highly desireable.  Applications that are latency
sensitive and/or send more than a few KB of data at a time would find
this beneficial - examples would include interactive games or web
search results being served over web sockets.

Since most of the Web Socket user agents are web browsers that already
support compression/content encoding for HTTP responses, I propose
adding support for optional content encoding to the Web Socket
protocol.  User agents could opt to accept compression, and servers
could opt to support it when the user agents accept it, just as is
done in HTTP.

This would mean the following:
- In requesting a web socket connection, if the client can handle
compressed messages the client would add an optional header line
Accept-Encoding just as is done for an HTTP request, for example
        GET /demo HTTP/1.1
        Upgrade: WebSocket
        Connection: Upgrade
        Host: example.com
        Origin: http://example.com
        WebSocket-Protocol: sample
        Accept-Encoding: gzip

- In response, the server could choose whether messages will be
encoded or not, and if so, can add a Content-Encoding header, for
example:
        HTTP/1.1 101 Web Socket Protocol Handshake
        Upgrade: WebSocket
        Connection: Upgrade
        WebSocket-Origin: http://example.com
        WebSocket-Location: ws://example.com/demo
        WebSocket-Protocol: sample
        Content-Encoding: gzip

- If the server has specified a content encoding, then all messages
sent by the server MUST have that content encoding applied.

Once the data transfer part starts, any message the server sends will
be exactly as currently specified, but with the content-encoding
applied.  The user agent must apply the necessary content encoding
transformation to the message, at which point the resulting data will
be as currently specified (i.e. framed by  0x00 and 0xFF or with the
appropriate framing for data that may include high bits.)

If the received message does not transform to a message that satisfies
the web socket protocol, either by not really being encoded in that
form or by the resulting decoded message not being properly framed
data, then the standard "fail the connection" step would happen.

I think a wide variety of possible web sockets applications would
benefit from compression.  What are people's thoughts on this?

-Doug Simpkinson
Software Engineer, Google