Henrik Nordström wrote:
>>I just checked the logs from earlier today...
>>the first PURGE request gave a 404 error so at that moment squid didn't
>>think it was really part of the cache... though I'm pretty sure those
>>files were cached at that moment:
>>1 second before the purge request there was a TCP_MEM_HIT for that object.
>>4 seconds after the pruge request there was a TCP_MEM_HIT for that same
>>object...
> So you saw
> TCP_MEM_HIT
> [nothing for that URL]
> PURGE 404
> [nothing for that URL]
> TCP_MEM_HIT
> If so then there must be a bug in PURGE. Not how it is intended to
> operate. This is assuming it really is the same URL, and not a minor
> variation of the same URL (such as different % escaping, case or similar
> sometimes minor differences)
the exact (well slightly obscured) log is:
[05/Sep/2002:16:40:02 +0200] "GET http://www.host.nl/index2.html
HTTP/1.1" 200 24769 TCP_MEM_HIT:NONE
[05/Sep/2002:16:40:03 +0200] "PURGE http://www2.host.nl/index2.html
HTTP/1.0" 404 199 TCP_MISS:NONE
[05/Sep/2002:16:40:07 +0200] "GET http://www.host.nl/index2.html
HTTP/1.1" 200 24769 TCP_MEM_HIT:NONE
note the difference between www and www2... www2 is the hostname of the
internal server as it gets translated by the redirector script. From
what I understand, the actual URL stored in the cache is that of the
internal host.
also note that the situation above was during a heavy session of
purge-request hammering... I'm pretty sure that if I do the same PURGE
request for this single URL it will work properly.
Regards,
Ricardo.
Received on Thu Sep 05 2002 - 15:50:38 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:10:07 MST