ERR_CLIENT_ABORT bug !!!!

I found why some people didn't see that ERR_CLIENT_ABORT bug !

People running Squid with "quick_abort OFF" or "quick_abort -1 0 0" can't see
this bug happening...

To make it happen you need to set "quick_abort ON" in squid 1.0.X or
squid 1.1.betaX

Try to access "http://www.quebectel.com" and look into your access.log ...

You'll see that every request produce an ERR_CLIENT_ABORT...

The problem is that Squid detects a "(254) connection reset by peer" within
IcpDetectClientClose() and produce an ERR_CLIENT_ABORT only if you have
quick_abort ON ! if not, Squid continues to get the URL and doesn't produce
any
error...

So if quick_abort is OFF this bug has no effect on Squid but if quick_abort
is ON
the URL is NEVER stored in the cache... (RELEASE)

It's definitly a BUG ... which occurs even if you don't have "quick_abort
ON" but
only has bad effects if you have "quick_abort ON" ...

The bad thing is that it happens only on some URLs and using some browers ...

BUT it ALWAYS happens on "http://www.quebectel.com" using Netscape (nav or
gold) 3.0
or earlier...

If you run squid using "quick_abort ON" (or whatever value "quick_abort 10
50 1000" ie)
look into your access.log and you'll see a LOT of erroneous ERR_CLIENT_ABORT !

How to make the difference between a real ERR_CLIENT_ABORT and a buggy
ERR_CLIENT_ABORT
with 1.1betaX :

If a real ERR_CLIENT_ABORT happens, you'll the that error message in
access.log & cache.log
BUT if it's a buggy ERR_CLIENT_ABORT you'll only the that error message in
access.log and NOT
in cache.log ....

So to know if this bug matters you:

1/ "fgrep ERR_CLIENT_ABORT access.log | wc"
2/ "fgrep ERR_CLIENT_ABORT cache.log | wc"

if 1 = 2 you don't have to worry about it ...
if 1 > 2 your cache doesn't store all the buggy requests and you lost some
BandWith :)

I hope that Duane will find it , because i tried to debug/trace the source
to see why/where
it happens but i didn't succeed :(
Received on Sat Nov 02 1996 - 19:51:43 MST