Search squid archive

Re: Multiple Ranges in Range: header - issues with non-sequential/overlapping ranges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux