- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 22 Jul 2011 11:54:46 +0200
- To: "Greg Wilkins" <gregw@intalio.com>, "Takeshi Yoshino" <tyoshino@google.com>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "Maciej Stachowiak" <mjs@apple.com>, "Arthur Barstow" <art.barstow@nokia.com>, "Adrian Bateman" <adrianba@microsoft.com>, "Ian Hickson" <ian@hixie.ch>, "ifette@google.com" <ifette@google.com>, "jonas@sicking.cc" <jonas@sicking.cc>, "simonp@opera.com" <simonp@opera.com>, "Brian Raymor" <Brian.Raymor@microsoft.com>
On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino <tyoshino@google.com> wrote: > Think of these facts, the only "dominant implementation" concern I can > come up with for WebSocket compression is that big service provides may > take an aggressive policy that they require users to use only WebSocket > client with compression capability to reduce bandwidth. As a result > clients with no > compression capability may, in effect, be kicked out of WebSocket world. > > I can understand that concern. Is this true for the HTTP world? I.e. > clients that send "Accept-Encoding: \r\n" cannot live? Yes. Optional features for browsers do not work. For servers it is fine if they do not support compression or whatnot, but browsers pretty much need to align on feature set. -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 22 July 2011 09:55:35 UTC