Yee Man Chan wrote:
>
> But my inspection of trace at ftp://ircache.nlanr.net/Traces
> told me that TCP_IMS_MISS always (as far as one trace is concerned)
> returns 200. Look at the size, it seems to me it comes with an
> object. I believe TCP_MISS/304 is closer to what you used to
> describe TCP_IMS_MISS. The size tell me this one does not come with
> an object.
>
> Did I get something wrong here?
No. You are right.
TCP_MISS is when we have no object to compare with, regardless if the
client sent a IMS query or not.
TCP_IMS_HIT is a HIT where the client has a up to date copy. -> 304
reply.
TCP_IMS_MISS is a really confusing entry. It is actually a cache HIT
on a IMS miss. Object is sent from the cache.
I think we should get rid of TCP_IMS_MISS and use TCP_IMS_HIT for both
cases. It if was a IMS hit/miss is obvious from the HTTP reply code
(304 == hit, all other miss). It is also more similar to TCP_MISS...
> BTW, how do Squid determine return code when it does not need to
> contact the server or when it only sends IMS to server to query
> about freshness?
On IMS hits (client has a up to date copy) the return code is 304
"Not modified". On all other replies the return code is what the
origin server returned on the request that generated the object
(return codes are cached with the object).
/Henrik
Received on Tue Jul 29 2003 - 13:15:51 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:50 MST