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

[Takeshi Yoshino]

Hi,

On Wed, Jul 20, 2011 at 08:06, Jonas Sicking <jonas at sicking.cc> wrote:

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


Sorry, I said too far about this. My main point is the assertion "they
wouldn't try to reject clients w/o deflate-stream".


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

It really tries to enforce browsers to use deflate-stream. I agree that
point. But even with this requirement I don't think we can avoid the bad
situation for servers that Hixie described in the bug entry. It just pull up
the ratio of clients in the world which never initiates WebSocket w/o
deflate-stream. Even without this requirement, server developers would
implement compression to make their server widely-used. Even with this
requirement, they would still leave their server accept un-compressed
connection for debugging and interoperability with non-browser clients. Just
IMHO.

But for service providers, yes, as you say the requirement may support them
in recommending clients with compression-by-default, or moreover in stopping
support of un-compressed connections, to reduce bandwidth and complexity in
load balancing, etc. So, I'll stop arguing this point.


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

Yes. For most case, their "primary" clients will be browsers, I agree. But
it's also true that IETF keeps it available for possible non-browser
clients.

According to your and Hixie's opinion, the API spec is indirectly attempting
to override the decision made by IETF and eliminate WebSocket w/o
deflate-stream support from both client and server from the world while "the
WebSocket protocol" still allows plain connection. Here we are introducing
inconsistency between the goal of "the WebSocket protocol" and one of "the
WebSocket API".  We are separating the world of "the WebSocket protocol for
the WebSocket API" and "the WebSocket protocol". It's rather really
interoperability problem. Please don't take indirect and majority power
based way silently but feedback to HyBi. We should respect/coordinate each
other's decision/philosophy. It's last resort that we instantiate a
dedicated "the WebSocket protocol for the WebSocket API".

In particular about enforcing or recommending regular use of compression,
once we've specified compression method good enough to recommend, I think
that's fine. But that still should be first discussed in the HyBi WG (with
coordination with the whatwg). deflate-stream is left optional because it's
just an example interim solution and getting objection in the HyBi WG. It's
waiting for better compression extension. We shouldn't extend this
un-stability to the API spec.


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

s/not require/require/?

Yes. Accepting deflate-stream or not can be decided by each server developer
and service provider on their responsibility.


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


Generally I agree. But IMO connections w/ deflate-stream would be usually
implemented by composing deflater/inflater code with the code that handles
plain (w/o deflate-stream) connections. The situation is different from
supporting some feature A and B where A and B are really independent. There
would be little code that may get rotten. Rather, as I noted above the
complicated matter I'd worry about is
- to handle two kinds of connection with different characteristics mixed
- to handle inefficient clients for all time
from production perspective (load balancing, etc.).

Takeshi