Edit report at https://bugs.php.net/bug.php?id=61218&edit=1
ID: 61218
Comment by: bruzh2 at gmail dot com
Reported by: bruzh2 at gmail dot com
Summary: FPM drops connection while receiving some binary
values in FastCGI requests
Status: Open
Type: Bug
Package: FPM related
Operating System: Ubuntu 10.04.4 LTS x64
PHP Version: 5.3.10
Block user comment: N
Private report: N
New Comment:
php.ini
http://www.box.com/s/bpuv2ngqoh4mog8srl4d
php-fpm.conf
http://www.box.com/s/o81ruvvf8gx31sd456qm
Previous Comments:
------------------------------------------------------------------------
[2012-03-01 15:09:57] bruzh2 at gmail dot com
refine summary field
------------------------------------------------------------------------
[2012-03-01 12:04:42] bruzh2 at gmail dot com
Description:
------------
The function fcgi_get_params() checks fastcgi name-value pairs on their
effective sizes using fcgi_param_get_eff_len().
This works good only for zero-ended string values, but not the binary data.
Suppose we want to transmit binary data with zeroes in the middle.
In that case fcgi_param_get_eff_len() returns 0. That causes FPM to drop
FastCGI connection.
Test script:
---------------
How to reproduce (passing binary client address in BREMOTE_ADDR):
nginx server configuration:
http://www.box.com/s/dduo08uni67ilgjnn6rc
TCP session dump (tcpdump -ni lo port 4006 -X -s 0):
http://www.box.com/s/ukkyco8raeijvb3hr8ep
Expected result:
----------------
Expected: full response from PHP.
Actual result:
--------------
Actually got: TCP reset immediately after receiving data packet with FastCGI
request.
You may decode bytes sequence in the data packet. Bytes from 0x0094 to 0x00A5
are:
0x0094 = x0c = 12 (the length of "BREMOTE_ADDR" string)
0x0095 = x04 = 04 (the length of binary data)
0x0096-0x00A1 = "BREMOTE_ADDR" (the name)
0x00A2-0x00A5 = 0x7f 0x00 0x00 0x01 (the binary representation of IPv4 address
127.0.0.1)
I found something like FastCGI specs on
http://www.fastcgi.com/drupal/node/6?q=node/22#S5.2
"3.4 Name-Value Pairs
...
This name-value pair format allows the sender to transmit binary values without
additional encoding,
and enables the receiver to allocate the correct amount of storage immediately
even for large values."
Thus, I think assuming that all FastCGI data is a zero-ended strings is wrong.
I wrote a patch that removes check for non-zero byte after "end of string".
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=61218&edit=1
