Hi Henrik, Just today I came across this bug report submitted in January http://www.squid-cache.org/bugs/show_bug.cgi?id=2176 which appears to match my situation almost exactly. I'm at home at the moment so can't check exactly, but it appears that squid keeps the connection open and the client continues sending the request. Only sometimes (but noticeably often) does the connection appear to be ungracefully closed and the browser errors saying it was reset. I haven't packet sniffed squid <-> webserver yet, but I can do and post the results if that would help. It only appears to reset the connection on the larger posts, the guy who originally posted the bug report said it's posts over 8kb, I've yet to verify that, but certainly smaller sized posts work without issue. Yeah I'm aware that the MS auth schemes weren't exactly designed to work in harmony with HTTP authentication! Unfortunately needs must!! If you can offer any advice, or let me know what else I can to do help diagnose the issue, I'd be most grateful. Cheers Joe -----Original Message----- From: Henrik Nordstrom [mailto:henrik@xxxxxxxxxxxxxxxxxxx] Sent: Sunday 6 July 2008 22:54 To: Joe Tiedeman Cc: squid-users@xxxxxxxxxxxxxxx Subject: RE: httpReadReply: Request not yet fully sent"POSThttp://xxx/yyy.php"; On tor, 2008-07-03 at 15:00 +0100, Joe Tiedeman wrote: > It seems to be that IIS is sending the 401 response before squid & the > client have finished sending the initial request to it, after sniffing > the traffic with wireshark on the client, squid is forwarding the 401 > response before the client has finished posting the data. The interesting things is what happens after the 401 response. Do Squid close the connection before the client sent all of the request, or is the connection kept open allowing the client to continue sending the request? What about the connection squid<->webserver? The microsoft "schemes" NTLM / Negotiate and Kerberos is a bit at odds with how HTTP authentication works, which causes some quite odd corner cases.. How things are supposed to work in the "HTTP" way is that the connection is kept open and request data being read, but the client when seeing the 401 should immediately abort the transfer (by closing the connection) and try again with correct credentials. This can not be done in the connection oriented auth schemes and the client must instead transmit the whole request, even when it's known it is now going into the bitbucket.. may not be such a big deal when on a LAN/Intranet, but if over a WAN it can be very annoying.. Regards Henrik _____________________________________________________________________ Higher Education Statistics Agency Ltd (HESA) is a company limited by guarantee, registered in England at 95 Promenade Cheltenham GL50 1HZ. Registered No. 2766993. The members are Universities UK and GuildHE. Registered Charity No. 1039709. Certified to ISO 9001 and BS 7799. HESA Services Ltd (HSL) is a wholly owned subsidiary of HESA, registered in England at the same address. Registered No. 3109219. _____________________________________________________________________ This outgoing email was virus scanned for HESA by MessageLabs. _____________________________________________________________________
