Re: [hybi] permessage-deflate and missing asymmetric configurations

[Takeshi Yoshino <[e-mail]>]

On Thu, Oct 10, 2013 at 4:45 AM, Joakim Erdfelt <[e-mail]> wrote:

> Was the idea of having compression level as a configurable ever on the
> table?
>

Since each endpoint can choose any compression level as long as wbits and
context mode are negotiated, I didn't include compression level negotiation.


> Then we could simply state a compression level of 0, which would still
> create the deflate blocks, but do no real work or effort to compress.
>

IIRC, with only a few people but we reached consensus that we'll start
experimenting heuristics to choose compression on/off in UAs and also
updating API spec to allow webapps to turn on/off compression for each
message.

Adding extension parameters to turn on/off compression allows for disabling
client-to-server compression while enabling server-to-client compression
but it's per-connection level configuration. I was not sure if it's so
worthwhile to include such a halfway feature.


> As for having the endpoint code control behavior inside of an extension,
> that seems difficult to control or expose.
> For example: do we even have the ability, in javascript on the browser, to
> control the extensions that are offered? or interrogate the open connection
> to know what extensions have been negotiated?
>

Using the extensions attribute, we can know what extensions are negotiated.

Rough plan was adding some attribute or method or overloading send() method
of WebSocket to allow webapps to flip compression on/off.