Chris Woodfield wrote:
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
Also check what your backend server does when given that type of range
request. If its returning just the ranges squid will do so as well. If
its returning the 200 full object, squid will pass that on too, though
sometimes it should not.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
Current Beta Squid 3.1.0.7
