Re: Vary, store interface

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Thursday, January 18, 2001 9:01 AM
Subject: Re: Vary, store interface

> Nope. storeGetPublicByRequest(request).
>
> For range requests the request is a range. Where the actual range
> processing takes place is another matter, but I think it belongs at a
> higher level than the FS, but lower level than the client connection.
>
> This is the interface to the generic Squid object store, not neccesarily
> the FS implementation.
>
> /Henrik
>

Right. So somewhere in
clientProcessRequest
clientProcessRequest2
clientProcessMiss
clientCreateStoreEntry
fwdStart
fwdStartComplete
fwdConnectStart
fwdConnectDone
fwdDispatch
httpStart
httpSendRequest

I think the fwd* routines are not the appropriate place to decide how much needs to be requested, so http* is it?

Should the store return the same object for every range request on the same URL (after taking varies into consideration)? This then
makes range combining a store problem?

The actual steps that need to happen are:
determine if we have a complete miss or a full object hit
yes: as today
no:
    do we have some of the requested ranges in store, or are the partials for other ranges?
yes: perform a IMS range request on the first requested range (intersection of stored and requested range)
    If we get something other than 304: consider this a complete miss, invalidate the stored data and proceed to request the
remaining ranges withnormal requests
no: perform a normal request for the requested ranges.
     when it arrives, check for strong validation between our stored partials and the incoming entity. If they match integrate the
new with the old, if they don't, toss out the old.

Any gaps in there?
Received on Wed Jan 17 2001 - 15:37:34 MST