Re: More IMS

On Wed, 21 Apr 2004, Leeann BENT wrote:

> They show two calls to httpSendRequest. I've attached the log.

2004/04/20 14:57:28.094| httpAccept: FD 10: accepted
2004/04/20 14:57:31.638| clientParseRequestMethod: Method is 'GET'
2004/04/20 14:57:31.638| parseHttpRequest: URI is 'http://www.cs.ucsd.edu/~lbent/test.txt'
2004/04/20 14:57:31.638| parseHttpRequest: Client HTTP version 1.1.
2004/04/20 14:57:31.638| parseHttpRequest: req_hdr = {^M
}

2004/04/20 14:57:31.640| ClientHttpRequest::httpStart: NONE for 'http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:31.643| fwdDispatch: FD 10: Fetching 'GET http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:31.643| httpStart: "GET http://www.cs.ucsd.edu/~lbent/test.txt"

2004/04/20 14:57:31.641| STALE: age 1708 > max 600

2004/04/20 14:57:31.646| GOT HTTP REPLY HDR:
---------
HTTP/1.1 304 Not Modified^M
Date: Tue, 20 Apr 2004 21:55:47 GMT^M
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_jk/1.2.1 mod_ssl/2.8.12
OpenSSL/0.9.6b DAV/1.0.2 PHP/4.2.2 mod_perl/1.26^M
Connection: Keep-Alive^M
Keep-Alive: timeout=15, max=100^M
ETag: "21300a-5-40859617"^M
^M

2004/04/20 14:57:31.649| fwdUnregister: http://www.cs.ucsd.edu/~lbent/test.txt

2004/04/20 14:57:31.650| fwdComplete: not re-forwarding status 304

2004/04/20 14:57:31.653| clientWriteComplete: FD 10, sz 452, err 0, off 452, len 0x401c951c
2004/04/20 14:57:31.653| clientReplyStatus: transfer is DONE
2004/04/20 14:57:31.653| clientReplyStatus: stream was not expected to complete!
2004/04/20 14:57:31.653| comm_close: FD 10

OK. This looks pretty much what was expected. One clien request. IMS
initiated by Squid. Reply by Squid.

Then there is a second request.

2004/04/20 14:57:36.831| httpAccept: FD 10: accepted
2004/04/20 14:57:40.235| clientParseRequestMethod: Method is 'GET'
2004/04/20 14:57:40.235| parseHttpRequest: URI is 'http://www.cs.ucsd.edu/~lbent/test.txt'
2004/04/20 14:57:40.235| parseHttpRequest: Client HTTP version 1.1.
2004/04/20 14:57:40.235| parseHttpRequest: req_hdr = {^M
}

2004/04/20 14:57:40.236| ClientHttpRequest::httpStart: NONE for 'http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:40.238| fwdDispatch: FD 10: Fetching 'GET http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:40.238| httpStart: "GET http://www.cs.ucsd.edu/~lbent/test.txt"

2004/04/20 14:57:40.240| GOT HTTP REPLY HDR:
---------
HTTP/1.1 200 OK^M
Date: Tue, 20 Apr 2004 21:55:55 GMT^M
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_jk/1.2.1 mod_ssl/2.8.12
OpenSSL/0.9.6b DAV/1.0.2 PHP/4.2.2 mod_perl/1.26^M
Last-Modified: Tue, 20 Apr 2004 21:55:50 GMT^M
ETag: "21300a-5-40859c66"^M
Accept-Ranges: bytes^M
Content-Length: 5^M
Keep-Alive: timeout=15, max=99^M
Connection: Keep-Alive^M
Content-Type: text/plain^M
^M

2004/04/20 14:57:40.247| fwdUnregister: http://www.cs.ucsd.edu/~lbent/test.txt

2004/04/20 14:57:40.248| fwdComplete: not re-forwarding status 200

but now odd things happens.. and the request is indeed forwarded again, or
actually a little earlier..

2004/04/20 14:57:40.246| clientHandleIMSReply: http://www.cs.ucsd.edu/~lbent/test.txt, 381 bytes
2004/04/20 14:57:40.246| clientGetsOldEntry: NO, reply=200
2004/04/20 14:57:40.246| clientProcessMiss: 'GET http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:40.247| storeCreateEntry: 'http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:40.247| fwdStart: 'http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:40.249| fwdDispatch: FD 10: Fetching 'GET http://www.cs.ucsd.edu/~lbent/test.txt'

2004/04/20 14:57:40.249| httpStart: "GET http://www.cs.ucsd.edu/~lbent/test.txt"

This defenitely should not have ended up in clientProcessMiss. It should
have continued using the reply to the IMS request.

This indicates the case with a new entry does not work properly in
handleIMSGiveClientNewEntry(). I strongly suspect it is
httpReplyValidatorsMatch() which fails like discussed earlier (very
dubious conditions in there..)

To be honest I don't really see why this test is there at all. From what I
understand there is no way the reply entity can not be compatible with the
client request only because Squid added a IMS header to the original
request.

Robert: Can you please fill in on the logics on why
httpReplyValidatorsMatch() is used. What is the conditions which may cause
the new non-304 reply to not be compatible with the original request?

There is three calls to httpReplyValidatorsMatch().

a) clientGetsOldEntry

b) handleIMSGiveClientUpdatedOldEntry

c) handleIMSGiveClientNewEntry

I can not say I understand the purpose of any of these calls.

Regards
Henrik
Received on Wed Apr 21 2004 - 16:07:34 MDT