Hi Guys, I've also begun experiencing this issue with a few sites that we host internally, we have a Mediawiki and a Joomla CMS installation both of which use Windows Integrated Authentication (Kerberos not NTLM) behind a squid reverse proxy. The error seems to show up when doing a large POST such as uploading an image to the wiki or updating a large article in Joomla and is quite often followed by an error in Firefox saying that the connection was reset. 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. I'm really at a loss as to what we can do to either fix or work around the issue. I can't stop using WIA as it's the basis for all our single sign on sites. If there's anything else that anyone suggest I would really appreciate it! If I can help by providing any more information, please let me know Cheers Joe Joe Tiedeman Support Analyst Higher Education Statistics Agency (HESA) 95 Promenade, Cheltenham, Gloucestershire GL50 1HZ T 01242 211167 F 01242 211122 W www.hesa.ac.uk -----Original Message----- From: Henrik Nordstrom [mailto:henrik@xxxxxxxxxxxxxxxxxxx] Sent: Wednesday 13 June 2007 22:56 To: Sean Walberg Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: httpReadReply: Request not yet fully sent "POSThttp://xxx/yyy.php"; ons 2007-06-13 klockan 07:45 -0500 skrev Sean Walberg: > httpReadReply: Request not yet fully sent "POST http://xxx/yyy.php"; > > -xxx varies, yyy.php is usually the same (most of our POSTs are to the > same script anyway) > Reading up on it a bit tells me that this means that the web server > has returned data before squid finished POSTing the form. Yes. > This is > usually a PMTU problem in forward-cache scenarios though. I wouldn't > expect PMTU discovery to be a problem on an Ethernet segment where all > devices have the same MTU. No. PMTU is not relevant here at all. How the script behaves is relevant. If the script responds before reading the complete request then the above message will be seen. This may occur if a) The script fails while reading the request or b) The script doesn't really care what the POST data looks like, ignoring it. or c) The web server responded with an error. > My initial inclination is to get a packet capture, but these errors > are unpredictable so I might be sifting through a lot of data, and I'm > not even sure what it would tell me. The most important piece it will tell you is what the response from the script actually looked like when this problem is seen. This will tell you if the problem is the script / web server, or if the problem is related to Squid. 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. _____________________________________________________________________
