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

[Takeshi Yoshino <[e-mail]>]

On Fri, Apr 26, 2013 at 7:38 AM, Peter Thorson <[e-mail]>wrote:

> 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
>

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