Bug 12917 [1] has been discussed in at least bugzilla as well as e-mail
including this thread started by Adrian (Hixie's follow-up is [2]) and
Adrian's general Web Sockets LC thread [3].
This bug is currently resolved as WontFix and this resolution is
supported by at least Hixie and Jonas. Adrian, Takeshi and Greg have
argued against this resolution (i.e. they do not support deflate-stream
being a mandatory extension in the API).
What do others (Anne?, Maciej?, ...) think about this issue?
Given the Protocol is now in LC review, it seems relatively important to
align the API and Protocol.
-Art Barstow
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0242.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0193.html
On 7/8/11 5:44 PM, ext Adrian Bateman wrote:
On Friday, July 08, 2011 1:12 PM, Ian Hickson wrote:
12917 - "deflate-stream" should be an optional extension when
establishing a connection
Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling
the protocol spec
on what is optional in the protocol. The API spec should not
normatively mention specific
extensions. References to "deflate-stream" should be informative and
only provided as examples.
I strongly disagree. We must have interoperability amongst browser user
agents. Having some support compression and others not would lead to
authoring mistakes and will force us into either having or not having
compression based on how big sites first get this wrong.
It's fine to disagree, but you should disagree in the IETF working group where
this is made optional and not in the Web API. There will be other users of
WebSockets outside the browser and by implementing the protocol they won't be
required to implement this extension. In addition, there are still discussions
about whether this is an appropriate mechanism for compression since it requires
intermediaries to decompress the whole stream if they want to review messages.
There are still proposals to remove deflate-stream from the spec.
We think there are legitimate cases for implementing the protocol without
compression. That aside, however, we strongly disagree with one consumer of a
protocol, the Web API, making decisions to override the requirements of the
protocol spec.
Adrian.
