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
