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

2008-07-06 Thread Henrik Nordstrom
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


signature.asc
Description: This is a digitally signed message part


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

2008-07-03 Thread Joe Tiedeman
 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:[EMAIL PROTECTED] 
Sent: Wednesday 13 June 2007 22:56
To: Sean Walberg
Cc: squid-users@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.
_