Vary doubts

Hi,

I am analysing vary implementation in squid 3...
I have some questions concerning rfc2616 intrepretation...

It seems to me that squid deals with variants in a following way:

- 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())

- 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...
  in cacheHit() and varyEvaluateMatch()
          headers (of the entry's Vary header) and their values are assigned to
          request->vary_headers...
  another call to store is being made (via clientGetMoreData)
  this time storeGet gets an entry identified by method, url and
          vary_headears

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?

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

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 this case, squid wouldn't be able to return an entry without Accept,
even if the client Accept-Language would match with it...

My questions are:
Does squid want this kind of behaviour?
If yes, why?
Did I understand everything correctly?

Regards,
Mati.
Received on Thu Apr 22 2004 - 01:35:52 MDT