On Apr 17, 2009, at 7:45 PM, Amos Jeffries wrote:
> 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.
>
>
Just checked this; my backend server (apache 2.2) returns the correct
partial content with these types of headers. I have range_offset_limit
configured, so for these objects, any range request will result in a
non-ranged request to the backend.
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
> Current Beta Squid 3.1.0.7
>
Received on Sat Apr 18 2009 - 00:19:36 MDT
This archive was generated by hypermail 2.2.0 : Sat Apr 18 2009 - 12:00:02 MDT