Re: #445: Transfer-codings

On 4 April 2014 11:42, Matthew Kerwin <matthew@kerwin.net.au> wrote:
>> 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.)

I don't think that would be a good idea.  It would end up being an RFC
6919 "MUST (BUT WE KNOW YOU WONT)".  The point being that if you build
a feature that enables intermediary compression, it will be used for
intermediary compression.

> 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.

It would be naive to think that it wouldn't be applied naively.

>> 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.

I think that - on balance - Content-Encoding is a better alternative.

> 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.

I don't want to sound too negative about range requests, but it may be
that many of the cases that depend on range requests would be better
served by giving the things that you are pushing across the network
actual names, then using content encoding.

Received on Friday, 4 April 2014 20:29:42 UTC