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

From: Joakim Erdfelt <[email-masked]>
Date: Thu, 25 Apr 2013 07:53:41 -0700

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

---

From: Peter Thorson <[email-masked]>
Date: Thu, 25 Apr 2013 17:38:43 -0500

On Apr 25, 2013, at 09:53 , Joakim Erdfelt <[email-masked]> 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"
> 
>    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.
> 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)
> 
> --

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 26 Apr 2013 12:53:26 +0900

On Fri, Apr 26, 2013 at 7:38 AM, Peter Thorson <[email-masked]>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"
>
> 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
>

The minimal set of functionality necessary to conform to this spec as a
server is s2c_no_context_takeover. That's all. I believe Java SE can
implement it.

- Compression: use java.util.zip.Deflater and append 0x00 at the end. If
received s2c_no_context_takeover, just recreate Deflater instance for each
message.
- Decompression: add 0x00 0x00 0xff 0xff to the end of message payload,
decompress it using java.util.zip.Inflater. When you see the end of DEFLATE
stream, recreate Inflate object and continue processing the rest.

- You don't need to care c2s_max_window_bits and c2s_no_context_takeover.
Just don't send them.
- You can just ignore c2s_max_window_bits capability announcement coming
from the client since you don't use it.
- You should just reject requests with s2c_max_window_bits. Clients should
take the way Peter explained above.

We're not sure if window bits is win for WebSocket or not, so I'd prefer
having it in the spec now. If it turned out to be win, you might be asked
to support it by users. Otherwise, everyone forgets them. Anyway, you can
make your server conform to the spec by supporting only
s2c_no_context_takeover.

Similarly, the minimal set clients need to support is
c2s_no_context_takeover.

Thanks