Re: [hybi] Handling multiple compression method entries of the same extension

[Takeshi Yoshino <[e-mail]>]

On Fri, May 11, 2012 at 10:41 PM, Arman Djusupov <[e-mail]> wrote:

> Agree on the 2-d) choice. What I just don’t understand is why you have to
> prefix max_window_bits and no_context_takeover?****
>
> **
>

If we take 2-d), we'll echo back requested client parameters while
sending the server parameters. So, we need to add prefixes to distinguish
them. The example for 2-d) will be like the following for the "deflate"
method.

Request:
perframe-compress: method="deflate; s2c_max_window_bits=15"
Response:
perframe-compress: method="deflate; s2c_max_window_bits=15,
c2s_max_window_bits=8"

Note that there is another point which needs to be clarified. Theoretically
> the max_window_bits and no_context_takeover can even be asymmetric. It is
> possible to implement this extension in such a manner that there is context
> takeover in one direction and no content takeover in the other direction.
> Unless I missed something, the spec does not require the server to use
> exactly the same parameters as the client requested.
>

That's exactly what I intended to mean.


> **
>
> “a server MUST include an element with the "perframe-compress" extension
> token as its extension identifier in the "Sec-WebSocket-Extensions" header
> in its opening handshake.  The element MUST contain exactly one extension
> parameter named "method".  The value of the "method" extension parameter
> MUST be a compression method description.  The compression method
> description MUST be a *valid response* for any of the methods listed by the
> client in its opening handshake.”****
>
> ** **
>
> So it’s a bit unclear what is a Valid response, obviously thought it is
> compression method specific.
>

OK. I'll fix it.


> **
>
> “An endpoint that received this parameter MUST NOT use LZ77 sliding window
> size greater than the size specified by this parameter to *build frames*.”
> ****
>
> ** **
>
> So this parameter affects only outbound frames and each side sets the
> maximum window size for the remote side, but those parameters are not
> currently required to be the same. For example, the client can limit the
> server to 12bit window, while the server can set the client maximum to 15;
> that would mean that the client is free to use a larger window for sending
> messages, while the server has to stick to lower values. There are cases in
> which such a design does make sense.
>

Yes.