Unidentified subject!

Greetings,

I recently upgraded to Squid 2.0/RELEASE and one of the things I was looking
forward to was the byterange support. This was supposed to help brain-damaged
applications like Adobe Acrobat documents become cacheable when the remote
server supports byte ranges. However, in my experimentation with the new
Squid release, the byte range support does NOTHING to prevent PDFs from
always hitting the source site.

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.

What is the reasoning for rejecting byte-ranges that are not sorted in
increasing 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.

Thanks,
Chris Wichura
caw@cawtech.com
Received on Sat Oct 24 1998 - 16:47:49 MDT