Re: What is The logic of Vary Headers cachiness?

tor 2013-07-25 klockan 22:06 +1200 skrev Amos Jeffries:

> I don't see why those are necessary. At the x-vary level all that is
> necessary is the response details to be searched for in the request
> headers. ie if x-vary says variant has "Content-Encoding:gzip" then
> search for "Accept-Encoding:gzip" in request headers for a possible match.

Vary lists the requests headers the server side variant selection looked
at while determining which variant of the requested URL is right for
this request. Any number of different request header values can map to
the same variant.

The variant of an URL is identified by it's ETag value.

Caches uses If-None-Match on unknown requests to ask which variant among
the known set of cached variants is the right response for this request.
The result of an If-None-Match is a 304 listing the ETag of the variant
to respond with + updated response headers.

What you end up with is a map of

* Request headers as indicated by Vary
* Which variant (etag value) is the right response for the matching
request.
* Possibly updated headers for the response (Date, Last-Modied,
Set-Cookie, X-Whatever) carried in a 304 response to If-None-Match.

Headers from the 304 MAY update the base object identified by ETag if
desired (the boundaries is a bit blurred), but you need to handle aging
of the map data somehow. But from what was learnt in squid-2 I would
today prefer to handle them separately, giving each request variant it's
own set of headers and aging, only sharing response body.

This reduces X-Vary to just Vary + known etags, where the etag values is
only required if the store can not index them by other means. A cache
hit would find the Vary, reiterate and look up based on request headers
as today, find the response headers, perform cache validation if needed
and get the response body from the store if needed.

But this requires a somewhat different store, and new pitfalls on what
to do if the referenced body suddenly is no longer there.

> If you have read the Key header specification this should be clearer. I
> am thinking the x-vary acts like a list of ETag values (for ETag match),
> Digest (for Digest match), and Key patterns (for Key/Vary matches) with
> Vary being a special vague case of Key. It stores a set of variants
> using *only* the exact details causing that variant to exist in the set,
> none of the request-header garbage like entire Accept: header or ignored
> field-values.

Vary is based on entire headers. We have no indication which parts of
the header the server looks at or what rules it applies when selecting
the variant. For some headers such as Accept-Encoding we can guess, but
not know.

Key tries to cut that down a bit, but getting Key correct is
non-trivial.

> Even the Cookie case should be greatly reduced with the use of Key
> header. Although that will take some time to occur. We can avoid that a
> bit by hacking an omit for Vary:Cookie sites just like Varnish does,
> unless they use Key to specify *which* cookie detail to inspect.

Imho the Key header is a dream. But sure having support for it as well
would be nice. But it is not an escape from supporting Vary.

The issue Key tries to address isn't really that big, if ignoring
Cookie. And it's very unlikely site owners manages to specify Key
correctly, they already have a hard time even doing Vary right.

Even the most basic Accept example in the Key draft is flawed. The
example will also match "Accept: text/html;q=0", plus completely fails
in representing quality at all. I.e. consider two clients one preferring
HTML one preferring plain text, but both can handle both if absolutely
required (i.e. the usual case for Accept*).

Regards
Henrik
Received on Thu Jul 25 2013 - 18:54:46 MDT