I've come across what appears to be a bug in Squid's handling of POST
requests when returning an error to the client.
If the UA makes a POST request with a reasonably large object (e.g. a
file upload of a few megabytes) and Squid needs to return an error (I've
tested this for 403 and 407 responses), it returns the response
immediately after receiving the request headers. The client continues
to send the POST body and Squid continues to read it. However,
eventually, Squid logs:
2013/01/17 17:50:50.780 kid1| client_side.cc(2322)
maybeMakeSpaceAvailable: request buffer full:
client_request_buffer_max_size=524288
Squid stops reading from the client and since the client is still
sending, the socket's rx queue grows. Eventually the rx queue is full
and the TCP stack shrinks the TCP window to 0. The client and Squid
both sit there doing nothing with an open socket until the client drops
the connection (which may be some time).
So, it seems that Squid is storing the POST body in an internal buffer,
waiting to do something with it that will never happen.
This is reproducible by setting an ACL:
http_access deny all
Then make a large post request via the proxy:
curl --proxy http://yourproxy:3128 -v -F foo=@somefile -H "Expect:"
http://someurl
Where "somefile" is a file of a few megabytes in size.
I've seen this in the field with Internet Explorer and proxy
authentication - uploading a file can result in IE making the initial
unauthenticated request and then hanging, waiting for the upload to
complete before redoing the request with auth credentials.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com
Direct contacts:
Instant messager: xmpp:st...@opendium.com
Email: st...@opendium.com
Phone: sip:st...@opendium.com
Sales / enquiries contacts:
Email: sa...@opendium.com
Phone: +44-844-9791439 / sip:sa...@opendium.com
Support contacts:
Email: supp...@opendium.com
Phone: +44-844-4844916 / sip:supp...@opendium.com
