Re: #445: Transfer-codings

I still don't think compression at the protocol/stream layer makes sense.
In my experience, it never worked well in our (SPDY) experiments: it added
complexity, pened the door for lots of DoS vulnerabilities, increased
memory requirements, increased CPU requirements, and rarely helped w.r.t.
bandwidth for well-constructed sites which compressed their resources.

The cost/benefit here is extremely dubious.
-=R


On Sun, Apr 6, 2014 at 9:51 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> On 5 April 2014 16:16, Amos Jeffries <squid3@treenet.co.nz> wrote:
> >
> > On 5/04/2014 10:29 a.m., Matthew Kerwin wrote:
> > >
> > > "This field is optional and is only present if the ENCODED flag is
> set."
> > >
> > > Otherwise everyone would pay a 2-byte tax for something only a few use.
> >
> > Unless that tax were perhapse the incentive for implementations to
> > encode data more securely than plain identity encoding? while still
> > allowing identity encoding (value 0x0000) to be used.
>
> I don't know that it works that way. I think it'd be more likely to end up
> a tax on our ears, from everyone complaining about the overhead.  Although
> I do like the idea of having an explicit identity coding, in case someone
> wants to give it a zero (or other low) rank in their settings.
>
> > >
> > > Michael Sweet <msweet@apple.com> wrote:
> > >
> >
>
> > > > Given some of the security concerns that have been voiced on this
> list, I
> > > > think it would be reasonable for a gateway to forward gzip'd data
> provided
> > > > that the other end supports it, but not to introduce gzip since the
> gateway
> > > > probably lacks the context needed to know it is safe to compress.
> > >
> > > Indeed. I guess that since -- as Ilari and mnot pointed out -- this
> differs
> > > from TE in the compression contexts, it makes it hard for a 2->1.1
> gateway,
> > > and even harder for a 1.1->2. That's an issue with this propsal, which
> is
> > > hard to address nicely.
> >
> > Not much more so than with the current draft. Gateways are forced to
> > uncompress and send as identity+chunked in HTTP/2 at present.
> >
> > Also, why would a 2->1.1 gateway go to the trouble of compressing ?
>
> I think I was comparing the per-DATA compression context to 1.1's single
> megacontext; if we had the latter, and everyone was playing along, then the
> gateway's job could be a lot easier in either direction by just forwarding
> blindly. However compared to the current draft (with no compression on the
> 2-side) then yeah, I don't think this proposal is adding too much work for
> anyone.
>
> Especially since the minimum effort for compliance is just not barfing on
> a SETTINGS frame of type 5, and making sure DATA FLAG bit 6 is clear.
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>