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

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.

--- A normal communication between browser and load balancer looks like
this:

A TCP connection is established and the HTTP request-line, headers, and POST
data comes across in a single packet.

No. Time Source Destination Protocol Info
837 8.276139 205.132.251.189 216.218.227.166 TCP 1428 >
http [SYN] Seq=743641091 Ack=0 Win=64240 Len=0
838 8.276241 216.218.227.166 205.132.251.189 TCP http >
1428 [SYN, ACK] Seq=912464831 Ack=743641092 Win=8000 Len=0
839 8.284837 205.132.251.189 216.218.227.166 TCP 1428 >
http [ACK] Seq=743641092 Ack=912464832 Win=64860 Len=0
840 8.285995 205.132.251.189 216.218.227.166 HTTP POST
/highstakes HTTP/1.1
841 8.286593 216.218.227.166 205.132.251.189 TCP http >
1428 [ACK] Seq=912464832 Ack=743641818 Win=8712 Len=0
844 8.292889 216.218.227.166 205.132.251.189 HTTP HTTP/1.1
302 Found
845 8.292890 216.218.227.166 205.132.251.189 TCP http >
1428 [FIN, ACK] Seq=912466133 Ack=743641818 Win=8712 Len=0
846 8.302025 205.132.251.189 216.218.227.166 TCP 1428 >
http [ACK] Seq=743641818 Ack=912464832 Win=64860 Len=0
847 8.303381 205.132.251.189 216.218.227.166 TCP 1428 >
http [ACK] Seq=743641818 Ack=912466134 Win=63559 Len=0
848 8.303793 205.132.251.189 216.218.227.166 TCP 1428 >
http [FIN, ACK] Seq=743641818 Ack=912466134 Win=63559 Len=0
849 8.303932 216.218.227.166 205.132.251.189 TCP http >
1428 [ACK] Seq=912466134 Ack=743641819 Win=8712 Len=0

--- When a request is made through the proxy, the communication looks like
this:

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.

No. Time Source Destination Protocol Info
529 14.353271 205.132.248.3 216.218.227.166 TCP 2157 >
http [SYN] Seq=4157170498 Ack=0 Win=57344 Len=0
530 14.353351 216.218.227.166 205.132.248.3 TCP http >
2157 [SYN, ACK, ECN] Seq=1666303205 Ack=4157170499 Win=8000 Len=0
533 14.361942 205.132.248.3 216.218.227.166 TCP 2157 >
http [ACK] Seq=4157170499 Ack=1666303206 Win=57960 Len=0
534 14.362517 205.132.248.3 216.218.227.166 HTTP
Continuation
535 14.362519 216.218.227.166 205.132.248.3 TCP http >
2157 [RST] Seq=1666303206 Ack=0 Win=1 Len=0
536 14.362865 205.132.248.3 216.218.227.166 HTTP POST
/highstakes HTTP/1.0
537 14.362866 216.218.227.166 205.132.248.3 TCP http >
2157 [RST] Seq=1666303206 Ack=0 Win=0 Len=0

--- Here are my questions:

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.
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.
3. Should Squid re-attempt the request when it receives the RST from the
load balancer?
4. Is there any way to configure Squid to forward the POST request as a
single packet?
Received on Wed May 21 2003 - 16:31:20 MDT