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
