Re: #445: Transfer-codings

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.