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
