W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Range Requests vs Content Codings

From: Roland Zink <roland@zinks.de>
Date: Mon, 23 Jun 2014 12:06:29 +0200
Message-ID: <53A7FC25.7080007@zinks.de>
To: Zhong Yu <zhong.j.yu@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 18.06.2014 18:35, Zhong Yu wrote:
> However, byte range solves a real, important use case - that in our 
> current world, downloading a resource may take very long time, during 
> which time various events can and do interrupt the download. Resumed 
> download via byte range probably helps millions of users every day. 
> But we cannot say that about bbcc, by any measure, therefore the merit 
> of byte range cannot be automatically extended to bbcc. The proponents 
> of bbcc need to uncover a lot more benefit of the feature to justify 
> its cost. Zhong Yu http://bayou.io 

There is another use case where range requests are used every day by a 
lot of users and this is playing (mp4) videos. Players usually offer to 
seek forward and backward within a video. This can't be done with 
content-encoding gzip, so this is one reason why gzip is not used in 
this case. You can argue that videos are already compressed and don't 
need C-E gzip, however for something like online encoding (and 
transcoding) this is done by guessing a bitrate adding some slack to it 
and fill the unused bytes with some constant values and compress most of 
the additional bytes away. Of cause this can be done on the application 
level as well, so you get something more advanced like HLS or DASH.

Even for the download this means the resumptions can't switch from 
uncompressed to compressed and vice versa. Caches may also need to store 
both versions.

Received on Monday, 23 June 2014 10:06:51 UTC

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