Re: More IMS

From: Micha³ Matusiak <m.matusiak@dont-contact.us>
Date: Thu, 22 Apr 2004 12:15:41 +0200

Helou

I will try to describe the situation step by step:
1. reource is found in store and is STALE
2. processExpired() is called
3. Squid generates IMS and sends it to the server
4. As a reply Squid gets new resource with 200 status code

We know that this means:
resource has been modified on the server and this is a new version
if the new version is cachable Squid should replace his copy resource
with the new one and check client IMS (if present)
Squid should send 304 or 200 (new resource) to the client.

But the following happens:
Squid gets 200 and in handleIMSReply() clientGetsOldEntry() returns
"false" because httpReplyValidatorsMatch() returns "false".
This happens because new resource has new values of some headers
(for example, has a new one Last-Modified which is fine, bacause
the resource has changed).
Then Squid calls handleIMSGiveClientNewEntry().

Let's assume that client's request was unconditional (without IMS) to
simplify our considerations.

In handleIMSGiveClientNewEntry() control flows to processMiss()
(this is done because of httpReplyValidatorsMatch()).
In processMiss() Squid sends new request to server. This time it's
conditional one (which seems to be wrong, but I'm not sure) too!
The second response from server is the same, replaces old cached
response and is being sent to client.

In my opinion this is a bad behaviour.

In handleIMSReply() we should check if the server response is 200 and
send it to the client. Also, new response should replace the old one.

We are correcting this (We = me & Mateusz Srebrny ;).

But we have some problems and we need your help.
Problems:
1. handling reply codes other than 200, 304.
    what we have to do with 4xx,3xx,2xx?

2. when 200 is received: we should replace old copy.
    we are going to use storeEntryReplaceObject().
    Is this correct? Are there any conditions that should hold?

3. httpReplyValidatorsMatch()
    let's assume that server responds with 304 and there is no
    Last-Modified header in server reply (for example apache doesn't
    send Last-Modified header with 304 response).
    Squid considers new response headers as 'inconsistent' with his old
    ones. Clearly we can't say this is wrong response.
    We need to know what is the intended semantics of
    httpReplyValidatorsMatch()?

    Maybe there should be a difference between situation when
    'inconsistent' headers are returned and when some headers are
    simply missing.
    This function has also bug (in our opinion) which seems to be easy
    to correct:
         ...
              one = httpHeaderGetStrOrList(&rep->header, HDR_CONTENT_MD5);
          ...
          if (strcasecmp(one.buf(), two.buf())) {
            ...
          }
          ...
    strcasecmp() seems cause to SEG FAULT when one of the parameters is
    NULL. This is the case.

  Could you give me access to CVS? My account name is mmatusiak.

  Regards
  Mike Matusiak
Received on Thu Apr 22 2004 - 04:36:43 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Apr 29 2004 - 12:00:03 MDT