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

> 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.

I don't think this is true, actually. Looking at the code, from
http.cc:1128:

/* Abstraction break: We should interpret multipart/byterange responses
 * into offset-length data, and this works around our inability to do so.
 */
if (!we_do_ranges && orig_request->multipartRangeRequest()) {
        debug(85, 5) ("httpBuildRequestHeaders: Resetting original request ranges for multipart.\n");

        /* don't cache the result */
        orig_request->flags.cachable = 0;
        /* pretend it's not a range request */
        orig_request->range->deleteSelf();
        orig_request->range = NULL;
        orig_request->flags.range = 0;
}

So, when we're not doing ranges (i.e. range_offset_limit == 0KB) and we
have a multipart request, we don't put the response into offset-length
data.

The problem with this is that the offset in clientStreamNode.readBuffer
has already been set at this point (when the request first came in) and we
have no ability to reset it in http.cc (as far as I can see).

Please let me know if I'm wrong in this, it would make my life so much
easier. :-)

Leeann
Received on Thu May 15 2003 - 15:45:44 MDT