Re: Ranges: ??s and bug(?).

On Fri, 2003-05-09 at 10:54, Leeann BENT wrote:
> Hi All -
>
> I have been playing with the Squid's range request handling and I'm not
> sure that I understand how range_offset_limit is supposed to work. Here's
> my understanding:
>
> range_offset_limit -1 KB => All range requests are fetched from the
> beginning and cached. Squid serves
> up the requested range to the client,
> pulled from the whole object.

Yes.

> range_offset_limit 0 KB => All range requests are passed on as
> is, with no attempt to cache the
> objects.

Again, yes.

> range_offset_limit X KB => Range requests with an offset < X KB are
> fetched and cached.

Yes.

> I cannot get Squid to work the way I expect, however, with
> "range_offset_limit -1 KB", so I suspect I misunderstand what is actually
> supposed to be happening. Specifically, when I request bytes 5-500 (for
> example) squid passes the request through to the server, even though the
> range_offset_limit is set to 1KB.

There is a specific test for the offset limit - you should start there
in debugging this. IIRC a grep for weDoRanges should find this. (If we
do ranges, then we get the whole object and give the ranges to the
client).

> Also, I'm not sure I understand how this interacts with a suffix
> specifier, since at the time of the request there is no way of knowing how
> far into the file the suffix is. Should there be a default in this case
> (i.e. never cache because a suffix request implies the request is for the
> end of the file)?

I'd need to check to answer this for you. It's likely that the
interaction is:
 offset limit result
* - + suffix = grab everything
* 0 + suffix = just what the client requests
* + + suffix = just what the client requests.

> Finally, I think I have discovered a bug in the way Squid treats multipart
> range responses. Since the tempBuffer offset is pulled from the request,
> not the response (which has none since the body of the reply is the
> multipart response), the multipart response from the server is getting cut
> off. I've introduced the following check in my code, but I'm not sure it's
> the correct place for the check. I just check if the response contains
> ranges before assuming they do:

The squid range logic for 3.0 is:

when the result from the server arrives, extract into canonical
representation: that is, strip the multipart encoding.

when sending to the client, encode anew.

So: client_side should only ever see the identity data, in offset,length
blocks. If you see *any* of the multipart encoding in client side, then
there is a bug in the http.c side logic which parses and removes the
multipart encoding.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.