Re: More IMS

On Thu, 22 Apr 2004, Mike Matusiak wrote:

> A couple of questions:
> Let's assume Squid sent IMS to the server and received a response.
>
> Q1: Which cases should flow to processMiss()?

I doubt it ever should after a Squid cache revalidation, no matter if
there is a 304 or not.

There is a case on a forwarded client cache revalidation where this could
be the case, if the 304 then indicates the origin copy is newer than what
we have in the cache. At the moment we do not. (1.3.5 second last
paragraph)

But it is important that a Squid initiated IMS does not include any
conditions from the client request unless compatible with what we have in
the cache.

> Q2: In processMiss() Squid sends IMS again. Is this correct?

No. The request after a discarded IMS must not be an IMS.

> Q3: There can be a case when server responds 304 with Last-Modified
> which is different than cached reply's Last-Modified - this is the
> situation when servers sends 'garbage' reply. Should we consider this as
> a correct result?

Not according to the RFC. (see 1.3.5 reference above).

> Q4: Let's assume that response is 503 Service Unavailable. If there is
> no expiry information with that response we should "negatively cache"
> this one. Squid doesn't do this but sends old cached reply. Is this
> correct behaviour?

This is correct. In case revalidations of cached content fails due to
server (5xx) or communication error it is correct to send the stale reply,
unless the client request has conditions preventing the cached copy from
being used. A Warning: 111 should be added, and also a Warning: 110 if
the entity is stale. Squid currently does not add warnings to the
response.

> What with other responses that can be "negatively cached"?

What about them?

Regards
Henrik
Received on Fri Apr 23 2004 - 01:28:07 MDT