Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC

[Takeshi Yoshino <[e-mail]>]

On Mon, Dec 17, 2012 at 1:28 PM, Takeshi Yoshino <[e-mail]>wrote:

> b) move the method parameter into a new separate handshake header entry
> pros:
> - human readable
> cons:
> - introduces a new header not defined in 6455
>

I got a request from chairs to elaborate why I considered this to be a
disadvantage. Here are my thoughts about this.

1) To keep it able to use the same extension multiple times, we have to
associate entries in the Sec-WebSocket-Compression-Spec header with entries
in the Sec-WebSocket-Extensions header by adding ID for each of them.

Sec-WebSocket-Extensions: permessage-compress; id=0, bar-ext,
permessage-compress; id=1
Sec-WebSocket-Compression-Spec: id=0; max_win...
Sec-WebSocket-Compression-Spec: id=1; max_win...

This complicates the spec more than putting everything together in the
Sec-WebSocket-Extensions.

2) Everyone knows Sec-WebSocket-Extensions, but not
Sec-WebSocket-Compression-Spec. It's possible that headers not defined in
RFC 6455 are filtered out by some firewall, proxy, etc. For these two
extensions, it's ok since they're going to be well-known. But this approach
misguides everyone that extension configuration that doesn't fit should go
outside of Sec-WebSocket-Extensions. In the future, there'll be lots of
headers that intermediary developers must take care of.