Re: [squid-users] problem with HTTP POST request split into two packets

On Thursday 22 May 2003 00.31, Martin Dillard wrote:
> We are experiencing a problem because Squid takes a single POST
> HTTP request and splits it into two packets. The packets end up
> arriving in the wrong order and our load balancer can't inspect the
> latter packets (which come first) to determine how to forward them
> to real servers. The load balancer ends up sending a RST back to
> Squid, which forwards an error page to the client.

This is a sign of a very broken load balancer. I would not dream of
using such product in any production environment. It will surely fail
for very many uses even if it may appear to work in simple testing..

> The single POST request is split into two packets. The first
> contains the HTTP request-line method and headers. The second
> packet contains the POST data. The packet with the POST data
> arrives first.

Perfectly valid thing to happen. HTTP may be transmitted one character
per packet if you like and it still is fully compliant (but not very
efficient).

HTTP is a stream based protocol on top of TCP. How a HTTP session is
split into packets is irrelevant to HTTP and only a business of how
efficient the transport layer is operating.

> 1. Should Squid wait for a 100 status response from the server
> before sending the message body for the POST request? I see some
> discussion of this in the HTTP 1.1 specifications.

Squid is a HTTP/1.0 proxy and servers MUST NOT sent a 100 Continue to
Squid. As a result Squid MUST NOT wait for a 100 Continue..

> 2. Should there be something in the second packet that would
> identify it as the second part of a request? I can't see anything
> but I am using Ethereal which may be hiding some information.

The packets belong to the same TCP connection. HTTP is a protocol
ontop of TCP. Packets belonging to the same TCP session are clearly
identified by TCP based on the source ip,port / destination ip,port
and tcp window.

> 3. Should Squid re-attempt the request when it receives the RST
> from the load balancer?

It should not. Only user-agents are allowed to retry non-indempotent
request methods such as POST after sending the request. Some earlier
versions of Squid did occationally incorrecly retry POST and other
indemptent requests but this has been fixed.

> 4. Is there any way to configure Squid to forward the POST request
> as a single packet?

It might be possible to optimize how Squid sends data allowing your
host OS to optimize the transmission into a single packet. This
however will not solve the fact that your load balancer is very
broken and not suitable for load balancing HTTP or other TCP based
protocols. Quite likely this load balancer is having several other
issues as well and quite likely failing in very many configurations.
I would say it is simply taking way too many shortcuts for the job it
is claiming to perform.

-- 
Donations welcome if you consider my Free Squid support helpful.
https://www.paypal.com/xclick/business=hno%40squid-cache.org
If you need commercial Squid support or cost effective Squid or
firewall appliances please refer to MARA Systems AB, Sweden
http://www.marasystems.com/, info@marasystems.com