Re: What is The logic of Vary Headers cachiness?

On 07/25/2013 12:53 PM, Henrik Nordström wrote:
> 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.

Yes, of course.

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

Are ETags required by HTTP in a Vary context? Or is it just what you see
some origin servers implementing?

> 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.

Can you express the above in an n:m map form you mentioned earlier? What
maps to what?

I suspect your n:m map is a side effect of adding ETag optimization to
"straight" Vary support. In the straight implementation, there is no
If-None-Match optimization on top, just a hit (if Vary-controlled
headers match one of the fully cached responses) or a miss (if they do not).

I agree that if you want to add If-None-Match optimization, then you
need to collect all potentially useful ETags and map them to their
responses:

    X-Vary-Object for a given URL:
        a list of Vary header names
        a ETag-to-store_key 1:1 map

This is still not an n:m map you were talking about AFAICT, so I must be
missing something. Do you propose to map specific request header values
(for Vary-controlled headers) to ETags??

I also do not see why updated response headers belong to x-vary-object.
Would not Squid receive them in the origin server response or load them
from the cache? Why store them in x-vary-object?

Thank you,

Alex.

> 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 - 20:21:15 MDT