Re: Cache digests of partly-fetched objects?

On Wed, 4 Nov 1998, John Sloan wrote:

> A slightly disturbing entry in my access.log:
>
> 910128490.358 901992 193.149.91.70 TCP_MISS/200 2546614 GET
> http://malldl.nai.com/v95i320r.exe - CACHE_DIGEST_HIT/haar.pipex.net
> application/octet-stream
>
> Why disturbing? Because the object in question is over 4Mb in size, which
> is greater than the maximum object size for my cache mesh.

Hmm.. I will try to check if we are digesting such entries. We should not.
 
> Do objects which are still being transfered make it into the cache digest
> somehow?

It depends on object headers and state. There is no reason why some [good]
objects cannot be digested while still in transfer, I guess. Also, because
of digest collisions, one can have a CACHE_DIGEST_HIT for an object that
was never digested in the first place.

Note that the fact that an object is placed into a digest can in no way
affect the correctness of the future hit transfer. If Squid cached a
partial object, it was a bug that should be fixed.

> The background for this is that I was investigating a complaint from one
> of our dialup users that they had tried to download this file via our
> cache several times, experiencing several pauses of over 60 seconds, and
> only once finding the patience to allow the download to complete. That
> time, they got a 2.6Mb file, which was incomplete.
>
> Eventually they disabled the cache and went direct. After having the
> connect drop halfway through the direct download, they tried again and it
> started from where it left off. Is this Byte range serving of some
> form? I've not come across it before. If it is, should Squid support
> it?

Squid does support resumed downloads. You will need to send us some
debugging information from cache.log so we can see what went wrong if
anything.

Thanks,

Alex.
Received on Wed Nov 04 1998 - 08:10:35 MST