Re: #445: Transfer-codings

On 5/04/2014 9:29 a.m., Martin Thomson wrote:
> 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.
> 

For some uses. For others TE in this proposal is better.

Content-Encoding suffers from the same weakness that allowed the Enigma
to be decrypted. The data type of each object is exposed in headers and
each data type has a known structure and commonly also a mime magic
prefix. This exposes it to decryption by comparing the known value
against encoded form. The entire object is encoded with the same context
allowing more fruit for picking.


In this proposal each DATA is able to be compress (or not) selectively,
or cycle through varous of the negotiated encodings on the DATA frames
by sending different encoding field value on each.
This encoding is also independent of the object cached by proxies. So
repeated requests for its URL do not necessarily produce the same
encoded response.


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


Amos

Received on Saturday, 5 April 2014 06:06:10 UTC