Re: [hybi] Payload only compression extension, again

[Takeshi Yoshino <[e-mail]>]

Thanks all. It seems that we'd
- add COMP bit
but for now
- leave advanced API, heuristics unspecified

And, as discussed in this thread a year ago
http://www.ietf.org/mail-archive/web/hybi/current/msg01810.html
I'm planning to add some parameters to this extension.

- Max size of LZ77 sliding window (and any other DEFLATE parameter if
useful)
-- requiring 32kB window for each connection might cause inacceptable memory
pressure for large scale system with lots of connection or embed system with
small memory
--- see the result of experiment done by spdy folk
https://spdy-dev.googlegroups.com/attach/4051c1467338d389/zlib_20100202.html?view=1&part=4
-- So, I'd add parameter "window_bits" to allow such endpoint to limit
sliding window size used by the other peer
-- if it's hard to get this negotiation into spec soon, the spec may
initially suggest some default values and limit based on these
investigation. Say, "endpoints MUST use sliding window of 2^12 or smaller".

Additionally, I'd like to propose one more parameter.

- No compression context sharing option
-- though I'm claiming that compression context sharing across frames is
good, it's sometimes harmful for intermediaries
-- for load balancers that dispatches WebSocket frames to different
backends, shared compression context means that the load balancer have to
perform decompression. it's burden in terms of both memory pressure and CPU
power.
-- So, I'd add parameter "finish_at_eof" to allow such intermediaries to ask
clients not to keep using the same compression context across frames