Re: [hybi] deflate-stream and masking

I vote for keeping it in the spec as it is now – an optional extension. Otherwise we will either remove deflate-stream and ship the protocol w/o compression and be subject to understandable criticism, or we will start discussing which is the optimal compression and further delay standardization until we complete deliberations. Otoh if we proceed with the spec as is then compression will be there, it will be optional, and we can return to add additional compression methods in the immediate future. No harm done to keep it in the spec as is, imho. Let’s ship. 

From: David Endicott [mailto:dendicott@gmail.com] 
Sent: Wednesday 20 July 2011 21:55
To: Alexander Philippou
Cc: Hybi
Subject: Re: [hybi] deflate-stream and masking

I'm basing my position on Greg's comment above that:

> I've just noticed that the w3c is currently intending to make support
> for deflate-stream mandatory!
>  <http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

If I cannot avoid it in my implementations (because browsers make it mandatory), then I'm strongly opposed.

If it remains an optional extension, then I revert to a Don't Care position.

On Wed, Jul 20, 2011 at 2:28 PM, Alexander Philippou <alex@noemax.com> wrote:

But currently it is an extension and thus optional, isn't it?

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of David Endicott
Sent: Wednesday 20 July 2011 21:10
To: Brian
Cc: Hybi; Greg Wilkins

Subject: Re: [hybi] deflate-stream and masking

Unlurking to agree.     

When it was optional it was avoidable and non-impairing.   It should not be mandatory.    

+6.02 x10^23 votes for removal from specification (which when deflated is just +1, I believe)

On Wed, Jul 20, 2011 at 5:50 AM, Brian <theturtle32@gmail.com> wrote:

+500.  deflate-stream has always been utterly ridiculous in light of masking.  It really should get the axe, and with extreme prejudice.  Why is it still in the spec?  I don't recall anyone citing a reasonable reason for keeping it, but there have been many very good arguments against it.  It's not even very clearly specified in the document -- when I implemented it in my Flash client, I had to read the source code of Andy Green's implementation to figure out how it was supposed to work -- his implementation became my specification for the extension.

Brian

On Tue, Jul 19, 2011 at 7:34 PM, Greg Wilkins <gregw@intalio.com> wrote:

I've just noticed that the w3c is currently intending to make support
for deflate-stream mandatory!

 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

This moves this extension from being useless, but mostly harmless, to
being a major impost on servers and intermediaries.
If the browser make this mandatory, then servers will obviously have
to support it at a cost of extra CPU, extra buffers but for no
significant savings in bandwidth.
Intermediaries that wish to act on frame boundaries will also have to
implement it.

This illustrate that having silly options always puts you at risk of
people taking you up on those options.

This extension is demonstrably broken and needs to be either fixed or removed.

regards

On 20 June 2011 16:33, Greg Wilkins <gregw@intalio.com> wrote:
> As part of my continuing campaign against including deflate-stream in
> the specification as a standard extension, I did a quick test of how
> well it works when applied to masked frames.
>
> I took a days worth of traffic from an IRC channel and wrapped it up
> as JSON messages sent as websocket frames.
> There were 487 message that looked like:
>
>     {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
> had issues pulling from github a couple of times  last week"}
>
> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!
>
> So for this very typical example, masking was sufficiently random to
> completely negate the benefits of compression.
>
> So the deflate-stream "extension" is:
>
>  + next to useless for inbound traffic
>  + breaks all the rules of what an extension can do
>  + is potentially vulnerable to injection as attackers can send
> repeated patterns that may subvert masking
>  + can be replaced by the in-frame compression extension already proposed.
>  + was inserted in the draft with little or no discussion and without
> clear consensus.
>
> Can I call for a straw poll of who wants to keep this extension in the spec?
>
>
>
> regards
>
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi