RE: handling ranges in squid-modio

 -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Thursday, February 22, 2001 9:16 AM
> To: Adrian Chadd
> Cc: squid-dev@squid-cache.org
> Subject: Re: handling ranges in squid-modio
>
>
> Adrian Chadd wrote:
>
> > 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. :)
>
> Reminder regarding ETag / Vary:
>
>
> The ETag support reuires one name, multiple instances with different
> ETags.
>
>
> The indexing layers involved:
>
> Request headers, mapped to ETag identities
>
> ETag identities mapped to entities
>
> entities have entity headers and data.
>
> The data part might consists of one or more fragments (partial objects
> store / ranges)
>
> For a non-varying objects the first two index layers is not
> needed. one
> name, one entity.
>
> /Henrik
 
To confirm my understanding:
there should be only one entity instance for any given Varies
combination?

(I.E. if varys is set to authentication, then potentially one instance
per `authentication header`)
of or varys is set to the content language header (sorry name escapes me
just now), then potentially one entity per language header.

So we want, single resource, multiple metadata sections with a body
each, and the body rangeable (sic0.

And finally when Etags & URL match, it is the same entity.
Rob

Rob
Received on Wed Feb 21 2001 - 15:37:13 MST