- From: John Tamplin <jat@google.com>
- Date: Wed, 20 Jul 2011 21:12:56 -0400
On Wed, Jul 20, 2011 at 6:54 PM, Adam Barth <w3c at adambarth.com> wrote: > Isn't the obvious solution to both problems to apply compression before > masking? > Yes. However, that is not what deflate-stream does. There has been a proposal for deflate-frame which would do exactly that, but it has not been accepted as of yet and there seems to be some resistance to including it in the base spec at the expense of further delaying it. deflate-stream was created as a "better than nothing" compression nobody objected to that served as an example in the spec of an extension. Since then, largely due to your work, masking client->server traffic was added which reduced the value of deflate-stream in that direction and also requiring the extension be handled outside the normal framing. The fact that the WS API would mandate deflate-stream and not allowing browser to support other extensions would in fact prevent the deployment of deflate-frame later, or for that matter any other improvements. I could hope that browsers would ignore that requirement and support other extensions, but then the spec isn't reflecting reality. As a further example, if multiplexing is added later, it may well need to have compression at a different level (otherwise mux/demux operations have to decompress and recompress) -- mandating deflate-stream would again complicate that scenario. -- John A. Tamplin Software Engineer (GWT), Google
Received on Wednesday, 20 July 2011 18:12:56 UTC