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

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