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