W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #445: Transfer-codings

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 7 Apr 2014 14:51:33 +1000
Message-ID: <CACweHNC0yHjNKsZDd0N_6LGTs+mZhBSTQTJ7jauR+jax2FKcig@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
> > > that the other end supports it, but not to introduce gzip since the
> > > probably lacks the context needed to know it is safe to compress.
> >
> > Indeed. I guess that since -- as Ilari and mnot pointed out -- this
> > from TE in the compression contexts, it makes it hard for a 2->1.1
> > and even harder for a 1.1->2. That's an issue with this propsal, which
> > 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

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
Received on Monday, 7 April 2014 04:52:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC