Is new XHR spec going to make gzip mandatory for its underlying HTTP?
On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor <Simetrical+w3c@gmail.com>wrote:
> From the discussion here, it sounds like there are problems with
> WebSockets compression as currently defined. If that's the case, it
> might be better for the IETF to just drop it from the protocol for now
> and leave it for a future version, but that's up to them. As far as
> we're concerned, if the option is really a bad idea to start with, it
> might make sense for us to prohibit it rather than require it, but
> there's no reason at all we have to leave it optional for web browsers
> just because it's optional for other WebSockets implementations.
>
Regarding deflate-stream, I think prohibiting is better than requiring.
But I still don't understand the benefit of banning any extension other than
what specified in the API spec.
There are two different assertions made by W3C side.
(a) it's not acceptable to make support (== request) of "good-compression"
optional
(b) it's not acceptable to allow any other compression/extension than
specified in the API spec
(a) is supported by the discussion you and Anne made by using analogy with
HTTP. I may agree with this. (b) is what Hixie was asserting in the bug
entry. I'd like to see clear support for (b).
No one knows what kind of compression will be finally the win for WebSocket.
I'd like to see ideas about how the evolution of WebSocket will be like.
With (b), to experimentally implement some extension/compression not
specified in the API spec, we have to make our browser non-compliant with
W3C spec.
I'd suggest that, once better-deflate is ready by IETF, W3C uses text like "
the user agent MUST request better-deflate extension" instead of "JUST
better-deflate extension".
Thanks,
Takeshi