[whatwg] Why deflate-stream is required to be enabled by the WebSocket API?
tyoshino at google.com
Tue Jul 19 04:16:27 PDT 2011
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?
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
/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
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
- usually both API and wire-protocol are implemented together by the same
Because of these two points, as a result, even clients can be easily ignore
Let keep wire-protocol level stuff handled by IETF.
More information about the whatwg