（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-1023Copy 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 能否代替分段加载？
事实上这种分段下载是同一次请求发起的，一次返回，并不能代替分段加载，另外很多解析库不支持
