Showing results for 
Search instead for 
Did you mean: 

HTTP POST request containing specific pattern fails.




I'm facing a problem that (presumably) WAF is causing HTTP connections to drop.

But I'm merely a user of a network which is presumably using BIG-IP ASM as WAF

device (in other words, I don't know details about that network). I'm trying to

collect information for reporting this problem to provider of that network.

Do you have any clue or article which resembles the following problem?


Description of the problem:


An HTTPS POST request which contains specific pattern causes that request to fail with

"curl: (55) TCP connection reset by peer" or "curl: (55) SSL_write() returned SYSCALL, errno = 32" error

in the middle of uploading POST data. Any HTTPS POST request which does not contain specific pattern

(e.g. POST data generated by "perl -e ' print "\n"x10485760 '") does not fail, though the time needed

for POST request varies depending on the contents of POST data. Thus, I'm suspecting that this problem

is occurring at WAF which can inspect POST data.


Steps to reproduce:


An example POST data containing specific pattern can be obtained by


 $ curl -o datafile.bin -r 6578036736-6588522495


. Sending that POST data to a CGI (which just consumes POST data)


---------- dev_null.cgi start ----------


echo 'Status: 200 OK'

echo 'Content-Type: text/plain'

echo ''

exec /bin/cat > /dev/null

---------- dev_null.cgi end ----------




 $ curl --data-binary @datafile.bin -k https://$destination/cgi-bin/dev_null.cgi




 $ curl -H 'Content-Type: application/octet-stream' --data-binary @datafile.bin -k https://$destination/cgi-bin/dev_null.cgi


causes the connection to fail after about 24 seconds. strace says that

curl starts sending POST data, then there is about 23 seconds of stall

where curl pauses sending POST data, and then curl resumes sending POST

data but detects that socket connection was closed. Also, access_log on

$destination server records HTTP 408 after 60 seconds, which means that

TCP socket's close event did not arrive at $destination server when curl

detected that socket connection was closed and gave up.


Additional info:


Sending same POST data like


 $ curl -F 'data=@datafile.bin' -k https://$destination/cgi-bin/dev_null.cgi


does not cause this problem. But if possible I don't want to use

'Content-Type: multipart/form-data; boundary=' in order to keep the program simple.



hello sir is your problem solved or not?

ok wait i will talk to this field people i have many people working in this field

until then just visit


official website



Not solved. I'm seeking for hints that could help solving this problem.


I got a response from a provider of that network that it is IPS which is dropping the connection,

for WAF records no message while IPS records "HTTP: Cisco HTTP Admin Authentication" message.

This means that BIG-IP ASM will be innocent for this problem. Although this problem is not yet solved,

closing this question as invalid. Sorry for the noise.