Re: #445: Transfer-codings

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/