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

Takeshi Yoshino tyoshino at google.com
Tue Jul 19 04:16:27 PDT 2011


Hi,

Use of deflate-stream is now mandatory in API spec. I think this kind of
requirement is useless. How about leave it up to implementors' decision?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

Adrian first brought this up on bugzilla for discussion. I'd like to ask
opinions from whatwg.

----

First, what effect specifying /extensions/ has is not yet clear for
client-side. Is this process intended to completely specify the set of
extensions wire-protocol uses? It's strange since we're going to introduce
multiplexing which is by nature not fully under control of JavaScript.

/extensions/ like this can be a hint, suggestion or request for
wire-protocol layer. According to Hixie's post (
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917#c5) here it's used as
mandatory extension request i.e. prohibiting WebSocket w/o deflate-stream
for browsers (but some other extensions can be added in wire-protocol
level).

----

I think this requirement doesn't really help us enforce endpoints
initiate/accept WebSocket with the same configuration. Because

- non-browser UAs are free to be implemented without deflate-stream
- server developers would see/care only the wire protocol spec

So, server developers would simply make their implementation accept both
requests with and without deflate-stream, I think. It's not likely that
server implementors are influenced by "the WebSocket API" and have their
server check if a UA is browser or not and reject requests w/o
deflate-stream. The only people who benefit from this requirement is those
who implement a server only for their own use and are not interested in
serving non-browser clients.

Even for such people, I think it's easier to debug and straightforward that
they implement one without deflate-stream and then with deflate-stream, and
then just leave both available. I can't imagine servers that has solid
implementation for deflate-stream but not for w/o deflate-stream. So,

- as most of servers support WebSocket w/o deflate-stream, no one would face
any difficulties to get their client implementation live
without deflate-stream
- usually both API and wire-protocol are implemented together by the same
person/vendor

Because of these two points, as a result, even clients can be easily ignore
this requirement.

Let keep wire-protocol level stuff handled by IETF.

Regards,
Takeshi


More information about the whatwg mailing list