Project

General

Profile

Bug #1644

Large HTTP Posts - get corrupted or just hang - with fastcgi PHP

Added by Anonymous almost 12 years ago. Updated over 11 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

Description:
------------
I use Freebsd 7.0 with lighttpd 1.4.19 and php-cgi 5.2.5 (with suhosin
patch). I run php-cgi with a external spawner.

I noticed, that when I do a large upload (1.2 megabytes) php works
unadequately: randomly it either corrupts the upload or just freezes.

So for instance, if I run php-cgi on a tcp port (1026) it successfully
accepts all uploads that are given to it from lighttpd and processes
them through the script. But randomly (sometimes several times in a row,
sometimes one out of 10 requests) it receives corrupted post data (several
bytes in the center of the 1.2 megabyte block get corrupted - replaced
with 00 00 00 hex values). Nothing freezes at this configuration.

If I run php-cgi as a unix socket (/tmp/php.sock) it either accepts the
upload (and never shows any sign of corruption, all data is processed
normally), or just halts and leaves the connection open (doesn't reply
to the current and any new connections either).
Sometimes it just unfreezes after a while and starts accepting new
connections, sometimes I just have to respawn php-cgi.

My best guess is that it might have something to do with the freebsd 7.0
socket handling. Maybe not - maybe it really is a bug in php-cgi or lighttpd.

Reproduce code:
---------------
Here is the command I use to make the upload from the remote host.

curl -vv -# -s -F "testfile=@debug.jpg" -H "Host: upload.host.ru" -H
"Expect:" -H "Content-Type:" -0 1.1.1.1:200/testupload.php

Note the empty Content-type - once I noticed the corruption, I decided
to make a test and debug HTTP_RAW_POST_DATA by hand. The corruption was
all the way up there.

Expected result:
----------------
The testupload.php script checks the HTTP_RAW_POST_DATA, extracts the
uploaded files from mime headers and checks it's md5 value. If MD5 is
incorrect, it logs the uploaded file and then I compare it to the normal
sample.

Interesting thing:
----------------

When I use "truss" (like strace) and attach to the lighttpd process, all requests get to the fastcgi unix-domain socket (/tmp/php.sock) without any problems. All code gets executed correctly, no hangs or corruption.

Once I turn off truss, lighttpd starts hanging the connection on random requests.

So I suppose that somehow lighttpd is related to the data corruption. And this corruption doesn't happen when I'm attached to the lighttpd process via truss.

-- eth

#1

Updated by Anonymous almost 12 years ago

Seems like server.network-backend="write" fixed my problem.
Took 24 hours to find out.
Strange.

-- eth

#2

Updated by Anonymous almost 12 years ago

server.network-backend = "write" started causing some strange "resource unavailable" errors in the error log, so I changed it to

server.network-backend = "writev" and everything went back to normal.

#3

Updated by Anonymous over 11 years ago

I have to confirm that bug. Very annoying for a stable release. POST requests reproducible hang the whole http server so I have to restart it. The writev setting fixed it for me but as I understand, this is optimized for a server doing large file transfers only. So for an all purpose webserver, thats a no-go.

#4

Updated by ethaniel over 11 years ago

writev works fine for me. both for large and small uploads.

#5

Updated by stbuehler over 11 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

Duplicate of #1675, fixed in r2256.

Also available in: Atom