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

 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_at_henriknordstrom.net]
Sent: Sunday 6 July 2008 22:54
To: Joe Tiedeman
Cc: squid-users_at_squid-cache.org
Subject: RE: [squid-users] 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.
_____________________________________________________________________
Received on Sun Jul 06 2008 - 22:41:23 MDT