W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] Why deflate-stream is required to be enabled by the WebSocket API?

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 20 Jul 2011 17:13:56 -0700
Message-ID: <CAJE5ia97Nuf9Kn8vRjSQtd-aM5+71HmSO+74+9T2OJqEz41f4A@mail.gmail.com>
On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 11:49 AM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>> The deflate-stream extension, when used for browser to server messages
>>> allows an attacker to put whatever bytes he likes on the wire, after a
>>> bit of unpredictable junk. Browser vendors were pretty opposed to that
>>> for the normal protocol without extensions, and they were opposed to
>>> having some way to make browsers send messages "unmasked"; so it would
>>> be very odd for browser vendors to implement the extension. And by the
>>> looks of it, the hybi Working Group may well drop deflate-stream now.
>>> See <http://www.ietf.org/mail-archive/web/hybi/current/msg07093.html>
>>> and <http://www.ietf.org/mail-archive/web/hybi/current/msg07581.html>.
>>Isn't the obvious solution to both problems to apply compression before masking?
> There is draft-tyoshino-hybi-websocket-perframe-deflate for that. It's
> not a solution to the problem Takeshi Yoshino raised though, which is
> about whether Websocket API conformance should impose restrictions on
> which Websocket extensions must and must not be supported, as far as I
> understand it anyway.

It seems pretty clear that the API specify whatever profile of the
protocol we choose.  We do the same thing with HTTP (e.g., with the
XMLHttpRequest API).

Received on Wednesday, 20 July 2011 17:13:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:34 UTC