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?
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...
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?
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.
is it correct?
I mean when server responds 304 squid won't be able to
cache the response...
ok... these are our questions.
> And regarding Vary... the two go intimately together. There is not very
> much value in implementing ETag if not having Vary using it.. If all you
> want it to implement the missing ETag functionality with no respect to
> Vary then the patch is basically not needed. The bulk of the patch
> implements the Vary+ETag combo.
ok... we think that full ETag support is also very powerful for the users
even wihout vary.
but we try to support vary anyway.
Currently we have about a half of ETag support implemented.
In a week or two we'll have it finished and then we'll go for the vary :D
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...
Anyway we collect our experiences with the code and after the vary
implementetion we will be able to contribute to the documentation also.
Regards,
Mati.
Received on Thu Apr 15 2004 - 03:08:39 MDT
This archive was generated by hypermail pre-2.1.9 : Thu Apr 29 2004 - 12:00:03 MDT