[squid-users] Multiple Ranges in Range: header - issues with non-sequential/overlapping ranges

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
Received on Fri Apr 17 2009 - 20:59:32 MDT