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

[Adam Barth]

On Wed, Jul 20, 2011 at 5:38 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Adam Barth wrote:
>>On Wed, Jul 20, 2011 at 4:56 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
>>> 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).
>
> HTTP allows you to send messages with `Transfer-Encoding: gzip,chunked`.
> Opera supports that in responses, most other browsers do not. The XML-
> HttpRequest specification takes no position on that, you can conform to
> it whether the XMLHttpRequest implementation supports that or not. The
> browsers do agree on supporting `Content-Encoding: gzip`, but again the
> XMLHttpRequest specification does not require or prohibit supporting it.

XMLHttpRequest imposes restrictions on the HTTP transport that are not
imposed by HTTP itself.  I don't see any reason why an API can't
restrict the protocol elements generated through the use of the API.
You can argue whether we should impose those restrictions, but we
certainly can.

Adam