[hybi] permessage-bzip2, -lz4 and -snappy

[Tobias Oberstein <[e-mail]>]

Hi,

we are experimenting with adding new compression methods to the PMCE framework provided by Takeshi's "permessage-compression" draft http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-09

Motivation:

While "permessage-deflate" balances CPU, memory and compression ratio and "zlib" is widely available, other compression methods either provide higher compression ratios (consuming more CPU and/or memory) or lower CPU and/or memory load.

We are thinking of

 - permessage-bzip2
 - permessage-lz4
 - permessage-snappy

We have already implemented "permessage-bzip2" in AutobahnPython (both client and server). The others will follow.

Here is an example opening handshake:


GET /runCase?case=6&agent=AutobahnPython/0.6.0 HTTP/1.1
User-Agent: AutobahnPython/0.6.0
Host: 127.0.0.1:9001
Upgrade: WebSocket
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: 900jKLXzMJ6OrZ3v9HgyOA==
Sec-WebSocket-Extensions: permessage-bzip2; c2s_compress_level, permessage-deflate; c2s_no_context_takeover; c2s_max_window_bits
Sec-WebSocket-Version: 13


HTTP/1.1 101 Switching Protocols
Server: AutobahnTestSuite/0.5.4-0.6.0
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 0sry1e2yduhqN51p9afaWmkcFnU=
Sec-WebSocket-Extensions: permessage-bzip2


When connecting from a client only supporting "permessage-deflate" (e.g. current Chrome Canary), server will fallback to that of course.

==

I'd like to ask on the list:

a) any interest by other implementors?

b)
- how should the new PMCEs be specified? within Takeshi's current draft or outside?
- how to register the extension names and parameters?
- does above even make sense, given that (as far as I know), none of bzip2, lz4 or snappy has an RFC?

/Tobias