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

[Joakim Erdfelt <[e-mail]>]

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]>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org