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

[Jonas Sicking]

> 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

Given the number of browser installations in the world (a couple of
billion or so), and that a significant portion of these will implement
the WebSockets API spec, it would seem downright irresponsible of
server developers to not look at it.

> So, server developers would simply make their implementation accept both
> requests with and without deflate-stream, I think.

I'd like to see a bit more meat on this assertion.

> 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.

Agreed. But it's not really servers job to ensure that browsers follow
the websocket spec here. Test suites and being able to claim that you
follow the spec should enforce that.

> 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.

First off, I suspect that the by far most common use case for servers
implementing websocket is to talk to browsers. So I would expect the
group you are talking about to be the majority of websocket
implementations. How many http servers do you think are out there
written primarily to talk to browsers?

Second, we're not really talking about browsers vs. non-browsers,
right. But rather clients that support deflate-stream vs. ones that
don't. So if a server expects to only talk to clients that support
deflate-stream, they might choose not require that. Even if some of
those clients aren't browsers.

Compare to the situation for http servers out there. I would expect
that a large number of them (as measured by codebases, not by
deployments) to have been primarily developed by testing what works
against browsers. I would further expect that non-browser clients,
such as web search spiders, end up having had to replicate some
browser behavior in order to be compatible with a larger set of http
servers.

> 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.

Untested generally ends up being non-working code. So while you might
end up writing without deflate-stream in the beginning, once you
implement deflate-stream, and have almost exclusively clients that
support deflate-stream, it's likely that your non-deflate-stream code
path ends up with bugs.

/ Jonas