Re: Unidentified subject!

Dear all,

I have similar problem with GetRight as well. The way that GetRight works
is retrieving objects via HTTP with byte-range. So that users can split
the download of some BIG files (e.g Netscape) in several times.

I discovered that if I set the proxy of GetRight to Squid 2.0 Patch 2
running at my Linux box, every time GetRight tries to resume the download
of a file (say, 10Mb was downloaded last time and I want to start from
there), Squid actually tries to pull the _whole_ thing back, ie Squid will
not respond to the request of GetRight until it finishes download the first
10Mb! This is driving me insane as I have to advice users to _not_ use the
proxy with GetRight.

So is there any way to get around it? I mean, I don't care if the big file
would get cached or not, but at least byte-range request should be allowed
to get through _without_ retrieving the whole file. Or as Alex said, we
have to wait for the next release?

Thx!
:Parabola

At 18:58 24/10/98 -0600, Alex Rousskov wrote:
>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.
>

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Intelligence is merely the accumulation of experience...
..
Parabola - the famous curve.
Email: mailto:parabola@ozemail.com.au
URL: http://parabola.home.ml.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received on Sun Oct 25 1998 - 05:19:42 MST