[whatwg] Why deflate-stream is required to be enabled by the WebSocket API?
w3c at adambarth.com
Wed Jul 20 17:13:56 PDT 2011
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
More information about the whatwg