Re: handling ranges in squid-modio

On Thu, Feb 22, 2001, Robert Collins wrote:

> > I'm *aiming* towards ripping out storeClientCopy() and replacing it
> > with the opposite of storeAppend(). THe header parsing and range
> request
> > code were the two places I saw the obvious non-linear store client
> > accesses.
>
> Uhmm, so non-linear is bad? I think non linear is good. (Think
> multi-range requests). I think backtracking however is really bad. (And
> I've got that fixed in rbcollins_filters. The server code buffers and
> parses the whole headers before it passes any of them on, so the
> client_side _always_ see the entire headers in the first read callback)

nono.. I mean store -> client is linear. The client can send to the
store a range request, and it'll get back a linear response. Whether
the linear response is a single or multipart response isn't relevant
here. The linearness is.

> > When I've tracked down any remaining ones I can continue reworking
> > the server/client data flows and then move on to sepearating the
> > header part from the data(body) part.
>
> Yes. Gor for it, delete away :]. I'll try to get a minimal intermediary
> in place in the next couple of weeks.

With what ?

> > We're assuming here that each object will have a "header" part and a
> > "body" part, right ? This would be a nice time to tell me.
> >
> > :-)
> >
>
> Every object that hits the store will have metadata and body.
> Metadata will include parsed protocol headers, time recieved by the
> cache....

Right.

> The Body is a set of potentially non contigous ranges belonging to the
> same instance of the object. (with offset 0 the beginning of the body,
> NOT the beginning of the response).

Right.

> This implies a function to write|update the metadata, and another
> funciton to retrieve it.

Right.

> The only question I have is "Varies" - does the store know about
> variations, or does the (currently hypothetical) intermediary make sure
> the store gets given different keys?

The store is going to know what to return to the client. The store
implements the vary support. Henrik and I outlined that different
features of HTTP/1.1 are going to be supported with varying profiles
(speed, savings, etc) and so its better left up to the store to choose
something cute.

So, single metadata section, multiple "bodies". Right. Uhm, I'll
keep that in mind and come back to you when I get to that stage. :)

Adrian

-- 
Adrian Chadd			"Romance novel?"
<adrian@creative.net.au>	 "Girl Porn."
				    - http://www.sinfest.net/d/20010202.html