Hi,
We've noticed that when a request is sent that has multiple byte
ranges in the Range: header, the behavior is not what one would expect.
If one requests multiple byte ranges that are sequential and do not
overlap (i.e. Range: bytes=1-20,30-50), the response is the expected
206 Partial Content with the requested data returned.
However, if one were to request multiple ranges that are either non-
sequential (i.e. Range: bytes=30-50,1-20), or are overlapping (Range:
bytes=1-30,20-50), the Range: header is ignored completely, and the
entire object is returned with a standard 200 OK response.
While neither of the above requests seems sensible or advisable, I
cannot find anything in the relevant RFCs that explicitly prohibit
Range: requests of this type.
Now what's interesting is that I tested this behavior against my own
squids, but then tested it against a URL on flickr.com, which per the
response headers is running the same 2.7STABLE6 we run. When querying
those servers, I did not notice the behavior.
URLs that can be tested -
Broken:
curl -o /dev/null -v -H "Range: bytes=20-30,1-10" http://cdn.semihuman.com/images/testtext.txt
Not Broken:
curl -o /dev/null -v -H "Range: bytes=20-30,1-10" http://farm1.static.flickr.com/64/226228060_c88ba6cf6b_b.jpg
So is this something that flickr has fixed in their private branch, or
is there a config option I'm missing to support this?
Thanks,
-Chris
