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: Sat, 5 Apr 2014 04:42:02 +1000
Message-ID: <CACweHNB063ooCHeLu+n3qhJPD_+wd5cU+OQ_76n=B_PcJmyxLw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
On Apr 5, 2014 2:28 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> In general, the trend has been to avoid generic compression and move
> to more context-aware compression.  That means that the entity
> performing compression has knowledge of what is being compressed and
> is therefore able to more accurately determine whether compression is
> safe to use.  This can be difficult, but it is the only way to ensure
> that using compression does not result in information being leaked.
>
> This is a step away from that.  A hop-by-hop compression feature like
> this will be applied without adequate knowledge of the consequences.

Would more words fix that? e.g. advice for intermediaries not to compress
packets they didn't recieve compressed? (And for Apache not to blindly
compress everything it receives from PHP.)

The current semantics of HTTP force this type of compression (i.e. not at
the 'entity' level) to be at the transport level, and thus hop-by-hop. That
doesn't have to mean that the compression is applied naively hop-by-hop.

> I don't think that we should be building features like this,
> particularly when there are better alternatives available.

This sounds like a snark, but it's not: what is a better alternative here?
C-E is an alternative, but it has deficiencies.

My goal with this proposal was partly to support compression on range
requests, and partly to de-emphasise the current practice of on-the-fly
C-E. To that end, I don't know of any alternatives at all.
Received on Friday, 4 April 2014 18:42:33 UTC

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