- From: Roland Zink <roland@zinks.de>
- Date: Mon, 23 Jun 2014 12:06:29 +0200
- 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. Roland
Received on Monday, 23 June 2014 10:06:51 UTC