HTTP 断点续传响应兼容问题

（1）、断点续传时Content-Length的角色问题

有时，在部分请求中，断点续传如果给了Content-Length，那么Content-Length是代表总长度呢还是本次传输长度呢？

举例：

我们可以请求资源的某一部分。这次我们依然用 cURL 来进行测试。"-H" 选项可以在请求中追加一个首部行，在这个例子中，是用 Range 首部来请求图片文件的前 1024 个字节。

curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"

Copy to Clipboard

这样生成的请求如下：

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023

Copy to Clipboard

服务器端会返回状态码为 206 Partial Content 的响应：

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
...
(binary content)

Copy to Clipboard

在这里， Content-Length 首部现在用来表示先前请求范围的大小（而不是整张图片的大小）。 Content-Range 响应首部则表示这一部分内容在整个资源中所处的位置。

（2）资源长度未知问题

有时候资源长度分片且未知，这个时候的响应头如何构造呢，实际上，Http允许我们传输未知长度的请求

// format is "bytes xxx-yyy/zzz
// where "zzz" is the total number of bytes of the
// content or '*' if unknown.

但是更具体的标准规范如下

Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/*
Content-Range: <unit> */<size>

但是我们发现，其中一个缺陷，要么“/”前面可以使用“*”，要么是后面，但是对于连range-end都不能确定的情况，总不能是 "*/*"吧？这种情况我们建议使用固定常量

const MAX_OUPUT_RANGE = 8*1024*8; //64KB

Content-Range: <unit> <range-start>-(<range-start> + MAX_OUTPUT_RANGE)/*

（3） Content-Type：multipart/byteranges 能否代替分段加载？

事实上这种分段下载是同一次请求发起的，一次返回，并不能代替分段加载，另外很多解析库不支持