Re: [squid-users] Malformed request

On Wednesday 10 July 2002 18.40, Miklos Magyari wrote:

> This message is originated from the parent proxy that serves my
> squid (it's a non-squid cache)
> So it seems that sometimes squid sends malformed requests; it
> inserts some strings before the HTTP GET.

More likely the parent proxy misunderstood a previous request on the
same TCP connection.

Try disabling server_persistent_connections in squid.conf. Might help
to work around the problem.

You can also try enabling broken_posts in squid.conf..

but before you try working around the problem, please collect some
data as described below.

> Can someone help me to track down the problem (my guess that it's a
> squid bug)?

Most likely the source of the error is a POST request prior to the
failing one. To tell who is at fault a detailed HTTP protocol
analysis is required.

Start by saving the traffic to/from your parent proxy to a file.

tcpdump -s 1600 -w trace.log host your.parent.proxy

make it fail one or two times.

use ngrep -I trace.log to identify the TCP connections. The output
will look something like

T 192.36.125.18:80 -> 10.1.1.3:40070 [AP]
  HTTP/1.1 50X Invalid request.....The system dete
  cted HTTP Error Invalid Request while attempting
  to retrieve the URL: ....

Note the local port number (40070 in the output above)

Extract the request stream for this connection alone

 tcpdump -r trace.log -w request_trace.log tcp src port
the_number_noted_above

Verify that you have got the whole connection, including the initial
SYN handshake

  tcpdump -n -r request_trace.log

the first line in the output should look like

16:04:54.295597 10.1.1.3.40070 > 192.36.125.18.http: S

and should be followed by a couple of lines like the following
examples

16:04:54.321391 10.1.1.3.40070 > 192.36.125.18.http: . ack
16:04:57.466579 10.1.1.3.40070 > 192.36.125.18.http: P 0:20(20) ack
16:04:57.672753 10.1.1.3.40070 > 192.36.125.18.http: P 20:22(2) ack

and finally a FIN

16:04:57.712067 10.1.1.3.40070 > 192.36.125.18.http: F 22:22(0) ack

If you don't get all of this, repeat the procedure until you do.

then decode request_trace.log into human readable form by using
ngrep..

  ngrep -I request_trace.log

and send me the output in private, or decode it yourself to see if
there is any HTTP protocol violations.

When sending me the output you may overwrite characters in the data to
hide private data, but it is very important that you do not
add/delete any characters. The character count in the packet data
must exacly match the output of ngrep, or else it won't be possible
to analyze the HTTP protocol correctly. Also, please send it as a
gzipped attachment to protect from mail systems messing around with
the data..

Regards
Henrik
Received on Thu Jul 11 2002 - 08:27:50 MDT