Subject: [hybi] [Compression] Parameter to suppress client-side compression

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 14 Nov 2012 13:30:13 +0900

Forwarding an off-list request I got on compression spec.

The proposal is adding a server->client parameter to suppress compression
on client->server data. It might be useful for applications where
client->server data is not worth being compressed.

Once we add some interface on WebSocket object to turn on/off compression
on outgoing data as planned, it'll be less necessary.

Thanks
Takeshi

---

From: Peter Thorson <[email-masked]>
Date: Wed, 14 Nov 2012 10:06:11 -0600

On Nov 13, 2012, at 22:30 , Takeshi Yoshino <[email-masked]> wrote:

> The proposal is adding a server->client parameter to suppress compression on client->server data. It might be useful for applications where client->server data is not worth being compressed.
> 
> Once we add some interface on WebSocket object to turn on/off compression on outgoing data as planned, it'll be less necessary.
> 
> Thanks
> Takeshi
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

In the absence of such an application facing interface to switch compression on or off is the intended default that a browser supporting permessage-compress would automatically compress all outgoing messages for a connection where permessage-compress was successfully negotiated?

Has there been any discussion of browser side interfaces for compression anywhere yet? I am particularly interested in whether these APIs will allow end user applications to switch compression on/off per message or only per connection. Have any browser vendors announced anything regarding their plans to implement permessage-compress yet? Is there any reason to believe that browsers will ship with permessage-compress without a method for javascript apps to signal whether or not to compress outgoing messages?

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 15 Nov 2012 11:39:58 +0900

On Thu, Nov 15, 2012 at 1:06 AM, Peter Thorson <[email-masked]>wrote:

> In the absence of such an application facing interface to switch
> compression on or off is the intended default that a browser supporting
> permessage-compress would automatically compress all outgoing messages for
> a connection where permessage-compress was successfully negotiated?
>

Yes. Or if there's any good heuristic, UAs can employ it to avoid
compressing messages that don't compress well.

>
> Has there been any discussion of browser side interfaces for compression
> anywhere yet?
>

There was. See
http://www.ietf.org/mail-archive/web/hybi/current/msg07923.html

> I am particularly interested in whether these APIs will allow end user
> applications to switch compression on/off per message or only per
> connection.
>

IIRC, people were discussing enabling per-message on/off.

>  Have any browser vendors announced anything regarding their plans to
> implement permessage-compress yet?
>

There's no work on API side yet, I think.

> Is there any reason to believe that browsers will ship with
> permessage-compress without a method for javascript apps to signal whether
> or not to compress outgoing messages?
>
>
Such an API can be added later without introducing incompatibility. The
protocol layer already has "permessage compressed" bit.

Thanks
Takeshi

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 29 Nov 2012 10:32:19 +0000

Takeshi Yoshino wrote:
>    The proposal is adding a server->client parameter to suppress
>    compression on client->server data. It might be useful for applications
>    where client->server data is not worth being compressed.
>    Once we add some interface on WebSocket object to turn on/off
>    compression on outgoing data as planned, it'll be less necessary.
>    Thanks
>    Takeshi

Where the server is supporting 100ks or millions of low-throughput
mostly-idle connections per server, it seems useful to disable
client->server compression for short messages to avoid the memory
overhead of having to receive and decompress them at the server.

This applies especially to keepalives, which are sometimes the
dominant traffic by far.

At the same time, when there is something more interesting and longer
to transmit, then it may be useful to compress it.  (Server can
allocate memory as needed, or even offload to another server if there
is a burst of activity on too many connections at once.)

So I can see an obscure use case for giving the client JS the option
to control this per message, or to set a message size threshold, or to
leave it set to automatic.  But it seems like a niche situation and
there are other strategies such as using multiple WebSockets in
parallel and/or writing a compressor in Javascript.

-- Jamie