Re: What is The logic of Vary Headers cachiness?

On 17/07/2013 10:29 p.m., Eliezer Croitoru wrote:
> As I have seen some issues that "indicate" that the Vary headers cause
> some problems while caching..
>
> I want to make sure I understand how a Vary headers should be treated
> before diving into some code.

Um, the "shodul be" rather than what Squid is currently doing with its
bugs...

On request:
  * lookup the URL / store-ID in the index
   ==> finds the x-vary-* object created by Squid for storeing the
vary_headers detail

* looks up the URL+vary / store_id+vary in the index
   ==> finds the real object
   ==> deal with caching using that variants response headers and the
request headers, same as any non-variant object would be handled if the
x-vary step had not taken place.

Also, I think if the variant needs to be invalidated Squid currently
coded to drop all variants and/or the main x-vary-* stub object during
revalidation. The HTTP/1.1 specs need to be checked to see if that is
right or if only the one variant object should be invalidated and the
others left for later requests to alter.

>
> My assumption is that there are "Vary" headers that the servers might be
> considering while answering the request.
>
> If the above is indeed right and my assumption of how squid caches vary
> headers There is a problem either in finding the corresponded responses
> or something else.
> Please help me understand how is the logic of The Vary headers works.
>
> Let say I have a requeset:
> ----
> GET /resource.dll HTTP/1.1
> Host: example.net
> Accept-Encoding: *.*
> -----
>
> the corresponding request will be:
> ----
> GET /resource.dll HTTP/1.1
> Host: example.net
> -----
>
> since there is no Vary field that indicates there is a Vary header
> present in the request, or the existence of a so called "Vary" header
> like "Accept-Encoding" is like stating "consider this vary header"?

The request *never* contains any indication of a Vary header. This is
why the stub x-vary-* object exists. Only after Squid looks up its cache
index and finds that x-vary stub object does it know that variants exist
on this object and the x-vary objects "vary_headers" details tells it
how to look up the particular variant needed by this request.

> if the request will be the same then OK.
> if the response is not the same then we have a problem.
> Would we calculate the Vary based on the request only or based on also
> the response?? and then when the response is not matching the request
> what will be the hash of the request?

Calculated based on the request headers (only) using the key details
stored in x-vary fake response object.

Amos
Received on Wed Jul 17 2013 - 11:35:01 MDT