Re: ETag support

On Thu, 15 Apr 2004, Mateusz Srebrny wrote:

> Hi,
>
> As we go on with our project some new questions regarding the code arose.
>
> i. the function cacheHit.
>
> We need to know when this function is called. I mean, it seems it is
> called in two cases: firstly when the entry client requested is found in
> the store snd squid has to decide what to do with it, and secondly, when
> client request was passed to the origin server and new entry is also in
> store and squid again has to decide what to return to requesting client.
>
> Is that all?

Sounds correct.

cacheHit is called to parse header data as it is being read in, and it is
this function which knows when the reply heaers have been fully seen.

In future it is planned to have this redone to split headers from the
payload, an pass around a already parsed reply header.

> There is some IMS mathcing so we figured it is good place to add ETag
> matching, and we want to know what can we assume on its flow context...

In principle where there is IMS matching ETag matching of this object also
belongs. There may be one or two special cases, but not much.

> ii. function httpReplyValidatorsMatch().
>
> It is called when server responded with 304 Not Modified and squid
> decides whether to pass this 304 to requesting client, or to return old
> cached entry... to be more exact there is an if:
> if (!httpReplyValidatorsMatch(..
> we analised the code and we think there is no possibility that in thath
> place this function would return false... is it true?

Hmm.. in what function? There is many such ifs with somewhat different
purpose.

> iii. let's say a client's request contains an If-Modified-Since header
> and squid has no matching entry so it has to pass the request to origin
> server... currently it passes the request with the IMS.

Yes.

> is it correct?

Doubtful, but it is a thin line.

Not forwarding the IMS on objects not in the cache gives more predictable
and stable results, but at the same time may significantly reduce the
local browser cache hit ratio..

> mean when server responds 304 squid won't be able to
> cache the response...

Correct.

In the simple world before Vary, If-None-Match etc these actually could
have been cached but we never got to it.

Now with the more expressive HTTP/1.1 validators 304 can no longer be
cached, as it is impossible to tell from the 304 reply alone which entity
it belongs to or if there is variance or not..

So for future it is probably best to not forward validators when nothing
is known about the object if we thing the reply may be cacheable. But then
we also risk breaking some applications which assumes cache validators is
end-to-end..

> ok... we think that full ETag support is also very powerful for the users
> even wihout vary.

Indeed. The ETag based cache validators is very useful in guaranteeing
consistent results.

> but we try to support vary anyway.
> Currently we have about a half of ETag support implemented.

Sounds great!

> In a week or two we'll have it finished and then we'll go for the vary :D

That will be an interesting experience involving many parts of Squid..

> and regarding documentation.
> we eventually found it in doc/programming-guide,
> but a quick glance on it suggests that places of our interests, ie
> client_side*, are not documented better than in squid 2.5...

Sorry to hear that. Should be a sign that it is still working more or less
in the same manner except for the C++ translation.

> Anyway we collect our experiences with the code and after the vary
> implementetion we will be able to contribute to the documentation also.

Sounds even better!
Received on Thu Apr 15 2004 - 04:51:34 MDT