Re: Vary doubts

On Thu, 22 Apr 2004, Mati wrote:

> - if a resource has a Vary header it is stored with two different keys:
> first got from method and url,
> and the second got from method, url and vary_headers (computed by
> httpMakeVaryMark())

There is two objects stored.

First a small marker object to make Squid remember this URL has variance
by the Vary header.

Then each object variant is stored by a key based on the method, URL and
Vary headers.

> - when a request for such a varying entry comes,
> method and url is used to compute the key and the first entry is
> retrieved from the store...

Yes.

> in cacheHit() and varyEvaluateMatch()
> headers (of the entry's Vary header) and their values are assigned to
> request->vary_headers...

Yes.

> another call to store is being made (via clientGetMoreData)
> this time storeGet gets an entry identified by method, url and
> vary_headears

Yes.

>
> I understand that when server replies with a different Vary header,
> it is stored with (method, url) key...
> This way variants that has other Vary header then the last one cannot be
> found...
>
> Am I right?

Yes.

> And more importantly, when I was reading rfc2616, I got an impression,
> that server can return different variants with different Vary tag...

Probably, but in most cases it should not. Having different Vary tags
makes a high risk for ambiguity on which variant should be returned.

Squid assumes that if the Vary changes then the rules for how the object
variance is determined has changed and it is best to throw away the older
entities.

> For example when client sends only an Accept-Language,
> server could respond with Vary: accept-language
> And when client sends Accept-Language, and Accept headers
> serever could respond with Vary: accept-language, accept

In both cases it should probably send "Vary: accept-language, accept".

Lets for example consider

   Accept-Language: en
   Accept: gzip

   Vary: accept-language, accept

And

   Accept-Language: en

   Vary: accept-language

Which of these two should then be returned in response to

   Accept-Language: en
   Accept: gzip

By their Vary headers both entities match the request as the second reply
says that Accept is not relevant in determining the variance of this
entity.

But if the server returns

   Vary: accept-language, accept

then it is crystal clear which entity should be returned in response to
each request.

If the fact that the existense of not of the Accept header is used
in determining the type of entity to return then accept should be included
in the Vary header, even if not present in the request.

With the addition of the entity index used by the ETag patch more
expressive variance can be recorded by Squid, but I think this safeguard
from change in variance still exists in that patch..

Regards
Henrik
Received on Thu Apr 22 2004 - 04:29:55 MDT