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
