Re: [hybi] permessage-compression / permessage-deflate configuration is too complex

[Peter Thorson <[e-mail]>]

On Apr 25, 2013, at 09:53 , Joakim Erdfelt <[e-mail]> wrote:

> How can a server side implementation respond on a the extension negotiation for this spec, using the permessage-deflate saying, "sorry, we don't support the C-library tweaks present in the spec and will only use default behavior" or to say "sorry, we don't support the C-library tweaks present in the spec and will only use the following behavior for both c2s and s2c streams"
> 
> The current language in permessage-compression-09 (Section 8) says:
> 
>    A server MUST decline a "permessage-deflate" offer if any of the following conditions is met:
>       o  The offer has any extension parameter not defined for use in an offer.
>       o  The offer has any extension parameter with an invalid value.
>       o  The offer has multiple extension parameters with the same name.
>       o  The server doesn't support the offered configuration.
> 
> That last bullet point is the crux of the problem I'm facing.  How can the negotiation indicate that "yes, i support permessage-deflate, but only this specific configuration, that doesn't match up to your configuration to permessage-deflate"
> 
> I'd like to propose that all of the following concepts be removed from the permessage-deflate and just standardized for specific default behavior based on a sensible set of defaults (lowest common denominator?), similar to how HTTP's content codings work (the http spec does not tweak compression algorithms) ...
> 
> c2s_max_window_bits
> c2s_no_context_takeover
> 
> s2c_max_window_bits
> s2c_no_context_takeover
> 
> from a Java point of view these are not possible to support without re-implementing the entire java.util.zip.Deflate library in each java application. (default Deflate support, that ships with every copy of Java since 1.0, just does not support these tweaks)
> 
> --
> Joakim Erdfelt <[e-mail]>

Section 8.1.3 explains how to handle this case:

A client sending: `Sec-WebSocket-Extensions: permessage-deflate; s2c_no_context_takeover, permessage-deflate` is asking "I would prefer that you reset the sliding window for each message, but if you can't then the defaults are acceptable." The server could then choose which copy of the extension request to return based on what it supports.

A client sending: `Sec-WebSocket-Extensions: permessage-deflate; s2c_no_context_takeover` is asking "I don't have the memory to spare for a default sliding window context per connection. We can compress if you support window resetting, if not we can't use compression."

Removing these options would not enable a Java based endpoint to compress connections that it otherwise wouldn't have been able to. It only removes the ability for non-Java endpoints to optimize their resource usage.

Peter