On Sat, 24 Oct 1998 squid-users@cawtech.com wrote:
> Having turned on section 11 debugging, I discovered that Acrobat NEVER
> requests ranges in sorted order of increasing ranges. This violates the
> range complexity rule in HttpHdrRange.c, resulting in we_do_ranges
> in httpBuildRequestHeader (in http.c) always being false, and thus the
> full PDF is not feteched and then parcelled out -- Squid just passes the
> byte range reqest through to the server and creates an uncacheable
> object that is immediately released as soon as the transfer is done.
Correct.
> What is the reasoning for rejecting byte-ranges that are not sorted in
> increasing order?
The reasin is the complexity of the code that has to be written. Squid
storage design does not allow for out-of-order ranges -- too many things
depend on the assumption that clients fetch bytes in order.
> Sure, if the first byte-range is from the end of the
> object, it may delay the user's response time as the bulk of the object
> must be transferred before one can start pushing data at the client.
> But I'd rather see the user stall for a bit and have the object cached
> than not cache the object and go back to the original source every time.
> Especially considering that the typical byte range object is a PDF, which
> are often fairly sizeable, and my link to the Internet is just a slow
> 56l DS0. The rewards of having the object cached for subsequent users
> far outweights the faster response for the initial retriever.
The limitation was not based on the response time optimization. It is simply
the amount of core code that has to be rewritten to support retrieval of
out-of-order ranges. Nobody expected that such a feature will exist in HTTP
when Squid storage was designed, I guess. You will have to wait for Squid 3.0
or Henrik writing a huge patch, whichever comes first.
Alex.
Received on Sat Oct 24 1998 - 18:35:56 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:46 MST