Re: X-Vary-Options patch

+1 to what H says. I'm definitely interested in this area, but want to
think through it a bit more.

We can get a certain amount of functionality without any extension;
e.g., canonicalising selecting headers to take care of whitespace and
case issues, and perhaps even ordering (this doesn't work for generic
headers, but where we know the semantics and ordering isn't
significant, it isn't a problem).

That doesn't take care of the qval problem, but it helps in the accept-
encoding case, which is the most common (I don't often see qvals on a-
e; anybody?). One of my concerns about X-Vary-Options (can we please
drop the 'X-'?) is that there are non-obvious corner cases; it forces
the origin server admin to think very carefully about all the
different variants that they're going to issue, and the request
headers that will match them. If we can get rid of the common cases by
canonicalisation, they will have less opportunity to mess things up.

Also, it's important to realise that at some point it's more
worthwhile to take an approach like TCN and describe the available
variants, rather than match against selecting headers.

Cheers,

On 07/06/2008, at 5:19 PM, Henrik Nordstrom wrote:

> On lör, 2008-06-07 at 10:43 +0800, Adrian Chadd wrote:
>> I think some of their stuff was backed out of Squid-2.7 before
>> release.
>
> The Vary invalidation patch was backed out from 2.7 as it's incomplete
> and broke things.
>
> But this X-Vary-Options patch never got committed. Thread stops after
> your request for him to file a bugzilla entry, and it got lost in the
> noise until found again by Mark.
>
> I have concerns about the completeness about this patch, for example
> if
> it handles q values properly. It's not such abig deal on
> Accept-Encoding, but can get quite messy if applying this to Accept or
> Accept-Language.
>
> For Accept* heaers I think it needs to be extended with an option
> instructing caches to parse the Accept* header to a limited degree,
> which means the cache needs to know the list of available choices for
> the header at the server and their order of priority.
>
> Also, for cookie it needs to be a little more elaborate as most often
> one wants to match on cookie names, not their vaule.. and sometimes a
> value of a specific cookie.
>
> Regards
> Henrik
>

--
Mark Nottingham       mnot_at_yahoo-inc.com