Re: #445: Transfer-codings

On 04.04.2014 22:29, Martin Thomson wrote:
> 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.
It is naive to think that Content-Encoding will not be applied 
hop-by-hop. Even though TE is hop-by-hop this doesn't mean that the 
compression and recompression must be done on each hop. If support is 
mandated then it should be sufficient to forward the pieces unmodified.
>>> 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.
Don't think so, except it is in use.
>> 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.
Actually it can be seen as a problem that by mandating content encoding 
support in the client the server decides on whether the client can use 
range requests for seeks, regardless if the client would prefer seek 
over CE. On the application layer this can be solved with some effort by 
splitting big entities on the server side and ship small pieces with 
every request, one example would be HLS compared to mp4. Such things can 
be done but come with their own complications.

Received on Friday, 4 April 2014 22:44:12 UTC