两次访问同一静态URL得到的文件长度不一样

现象

在使用chrome浏览器请求一个媒体服务器上的URL时，例如

www.video-server.com/media/videos/mp4/1.mp4

chrome在播放时会进行先后两次请求，应答的Content-Length不一致，具体情况如下（对请求地址做了修改改）：

第一个请求

GET http://www.video-server.com/media/videos/mp4/1.mp4 HTTP/1.1
Host: www.video-server.com
Proxy-Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

HTTP/1.1 200 OK
Content-Length: 9882602
Content-Type: video/mp4
Date: Sun, 24 Jan 2016 07:01:56 GMT
Etag: "2479115360"
Last-Modified: Fri, 16 Jan 2015 20:01:54 GMT
Server: lighttpd/1.4.28
X-Mod-H264-Streaming: version=2.2.9

第二个请求

GET http://www.video-server.com/media/videos/mp4/1.mp4 HTTP/1.1
Host: www.video-server.com
Proxy-Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
Accept: */*
Referer: http://www.video-server.com/media/videos/mp4/1.mp4 Accept-Language: zh-CN,zh;q=0.8
Range: bytes=0-

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 9882560
Content-Range: bytes 0-9882559/9882560
Content-Type: video/mp4
Date: Sun, 24 Jan 2016 07:01:57 GMT
Etag: "2483794507"
Last-Modified: Fri, 16 Jan 2015 20:01:54 GMT
Server: lighttpd/1.4.28

分析

仔细观察请求头部和应答头部，两次请求的User-Agent都一样,应答的Last-Modified都一样，区别只在于后一个请求使用了range方法，如下：
第一次请求
直接请求

应答Content-Length=9882602

第二次请求
Range: bytes=0-

应答Content-Length=9882560，比第一次少了42个字节。

经过查询1，对于H264格式的媒体文件，lighttpd服务器上根据请求方法是否携带range，选择mod_staticfile或H264 module两个模块应答。

如果不带range，即第一次请求，lighttpd服务器通过H264 module提供H264 streaming服务,其应答头部的“X-Mod-H264-Streaming”就说明了这一点，该模块会修改媒体文件的头部，比如moov atom，导致文件尺寸发生变化。

如果请求方法带range，即第二次请求，lighttpd服务器认为这是对静态文件的部分请求，由mod_staticfile module提供返回数据，客户端得到的是服务器上的原始文件。

思考

一个URL指向两个或两个以上的文件并不稀奇，比如桌面和移动端的浏览器对同一URL的访问会返回不同的页面。

但对于静态URL的访问，出现文中的情况就比较少见了，chrome浏览器本意是通过后续带有的range请求，提高视频的播放速度，没想到被lighttpd摆了一道。