[squid-users] Squid bug #499 - not all Microsoft's fault (maybe)

I experienced this problem and found out that the solution provided in
Q331906 was a bit fragile. While looking at this I found that Squid seems to
misbehaving and that this is what causes IE6SP1 to go off the deep end.

I ran a packet capture and compared the TCP sequences of a bad run with
IE6SP1 connecting to squid that doesn't authenticate vs. the same IE6SP1
connecting to another squid that does authenticate. The squid that doesn't
authenticate has an upstream proxy that does authenticate.

What I noticed real quick in the bad case was that the connection was being
shutdown right after the 407 response from squid, and it was being initiated
by squid and not by IE. It was at this point that IE lost the plot. I looked
a bit closer, and the 407 response has a keep-alive header, even though
squid clearly intends to close the connection. RFC 2068 says that squid
SHOULD send a close connection-token if it intends to close the connection.
Although it doesn't prohibit sending a keep-alive connection-token when you
want to close the connection, it doesn't take much to infer that this is
probably a bad idea.

Does anyone have a different view on this, or should I just file a bug
report?

Thanks,
Lloyd Parkes

Wellington Unix Team
EDS (New Zealand) Limited
Phone +64 4 474 5732
Fax +64 4 474 5094
Received on Mon Dec 29 2003 - 18:42:07 MST