RE: [squid-users] httpReadReply: Request not yet fully sent "POSThttp://xxx/yyy.php"

From: Joe Tiedeman <Joe.Tiedeman_at_hesa.ac.uk>
Date: Thu, 3 Jul 2008 15:00:53 +0100

 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_at_henriknordstrom.net]
Sent: Wednesday 13 June 2007 22:56
To: Sean Walberg
Cc: squid-users_at_squid-cache.org
Subject: Re: [squid-users] 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.
_____________________________________________________________________
Received on Thu Jul 03 2008 - 14:00:55 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 07 2008 - 12:00:03 MDT