Re: vary stuff

On Mon, Feb 12, 2007, Henrik Nordstrom wrote:

> > Would you mind if the Vary support was culled out of the storage work
> > branch until I've tidied up the storage manager layer somewhat?
>
> No problem. It's not really that tricky thing to support. The tricky
> part was getting it into Squid-2 without a suitable store interface or
> even intermediary layer..

Hm! I'll give it a shot this evening. I wouldn't mind it if you yanked
the code out of the storework branch before me though.. ;)

(And thanks for the caching description here!)

> 1. The client->intermediary "lookup" API needs to be async for it to be
> able to do the vary dance. May need multiple store lookups and possibly
> a conditional upstream request to find the correct response.

We'll have to do this to support a number of 'other' things, such as
the types of storedirs people have wanted over the past: eg md5-based
reiserfs access - performance may suffer but the memory footprint will
be drastically smaller!

From what I've heard from others (as I don't have a commercial web cache lab
here) commercial caches treat Vary content very, very simplisticly. We might
want to re-evaluate how we handle Vary - eg allowing for Vary header contents
to be 'normalised' (eg Vary: Accept-Encoding shouldn't Vary based on the
verbatim header contents as UA's are pretty arbitrary with their Accept-Encoding
headers; instead tokenise Accept-Encoding into a number of states and Vary
based on those states.)

But ok. If you or I or someone else feels up to it then lets yank the Vary
support out of the SF storework branch and leave it out until we've got the
rest of the store manager sorted. It does mean we might have trouble finding
testers (wikimedia probably won't as they really do want Vary support) but
I'll see what I can do.

Adrian
Received on Mon Feb 12 2007 - 16:40:11 MST