I have the same problem on my machine and can confirm this bug!
i think this bug affects mod_spdy aswell, because it sends the POST data chunked! 
( http://code.google.com/p/mod-spdy/issues/detail?id=22 ).

I've additionally tested the two files on nginx with PHP as FCGI. The request simply doesn't go throught to PHP and nginx gives 401 back. I've attached gdb to the PHP and set a break in the accept loop - there was no reaction when using the two test files, but requests without data got down to PHP. So my conclusion were - apache simply ignores the request body where nginx gives a correct http status. Anyways, this has nothing to do with PHP. IIS, Apache and Nginx seem to have no implementation for chunked incoming body stuff, but they do handle that a different way.

Btw. Nginx has the "chunkin" module for such actions.

@clarkwise at gmail dot com

So could you confirm it works with nginx+chunkin?

As well, it's was not hanging with IIS (v7.5) for me. Which IIS version do you 
have?

Since I am using Windows XP, I'm stuck using IIS 5.1. When I have the opportunity 
to try nginx w/ chunkin or IIS 7.5, I'll update with further details. Thanks.

Same problem here. Apache 2.2.15 and PHP 5.3.10 running as FastCGI.

POST datas sent with "Transfer-encoding: chunked" are not received as they should be. The raw request looks like this :

POST receiveChunk.php HTTP/1.1
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: keep-alive
Cache-Control: no-cache
Content-Length: 682668
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

3ff4
(here, the datas)
0

and the request as the receiving script sees it :

User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: close
Cache-Control: no-cache


As you can see, the request body is empty.

However, this problem does not occur when PHP runs as mod_php under Apache. Problem confirmed under PHP 5.3.8 and 5.3.9.

I don't know if that is a PHP bug and maybe the developers could confirm or not that the request body are wrong before it reaches PHP. I think that it appears to be a mod_fcgid bug and should be reported as one to Apache bug list.


Here are the scripts to reproduce the bug :

sendChunk.php :
<?php
$fileContentToUp = 'ICAgICAgICAgIgICAgIA==';

$header_array = array(
	'Pragma' => 'no-cache',
	'Connection' => 'keep-alive',
	'Cache-Control' => 'no-cache',
	'Content-Length' => strlen($fileContentToUp) ,
	'Transfer-Encoding' => 'chunked'
	);

$options = array(headers => $header_array);

$r = new HttpRequest('receiveChunk.php', HTTP_METH_POST, $options);
$r->setContentType('text/html; charset=UTF-8');
$r->setBody($fileContentToUp);
$result = $r->send();

echo '$r->getRawRequestMessage() => ';
print_r($r->getRawRequestMessage());
echo "\n\n";
echo '$r->send()->getBody() => ';
print_r($r->send()->getBody());
echo "\n\n";
?>

receiveChunk.php :
<?php
$HttpResponse = new HttpResponse();
echo 'http_get_request_header => '."\n";
print_r($HttpResponse->getRequestHeaders());
echo "\n\n";
echo 'http_get_request_body => '."\n";
print_r($HttpResponse->getRequestBody());
echo "\n\n";
?>

Hope that helps.

I forgot to mention that this is on a Linux system

The problem seems to have been resolved with php 5.4.0 and apache 2.4.1. I can't reproduce it with this configuration and chunked http requests are now coming through to php now.

I am going to try with php 5.3.10 and apache 2.4.1 and give feedback on where it goes.

Try a snapshot please, 5.3.10 has nothing else but security fixes unrelated to 
this issue.

First of all, the problem is still here with PHP 5.4 and Apache 2.4.1, I previously made the mistake to precise the content-length in my headers.

So here is what I found. If you send chunked http request but do not send the content-length (as we should do using HTTP 1.1 protocol) the body part of the request is empty (php://input returns nothing). This result remains valid for the following configuration where PHP runs via FastCGI : 

PHP 5.3.10 - APACHE 2.4.1
PHP 5.3-201203101230 - APACHE 2.4.1
PHP 5.4 - APACHE 2.4.1
PHP 5.4-201203101230 - APACHE 2.4.1

The same configuration with PHP running as mod_php is fine, the body request is available through php://input.

Making the chunked request to a stock nginx 1.0.13 installation
on Ubuntu yields a "411 Length Required" message, but enabling
the ngx_chunkin module does indeed correctly serve the request
and populate php://input and $HTTP_RAW_POST_DATA.

This was done with both Ubuntu's distribution of
PHP 5.3.6 and the php5.4-201203221530 snapshot.

So, it is not a PHP problem ?

@florian dot fernandez at navaho dot fr

Looks like that. Could you try nginx+chunkin to confirm please?

I finally got my hands on Windows Server 2008 running IIS 7.0.
Same problem; when POST request is chunked, the response times out.

Perhaps I'm missing a setting that would enable the receipt of 
chunked incoming requests, but I have only read about settings
that chunk the outgoing response.

@ab at php dot net

Unfortunately, I won't be able to test with nginx because the system administrators won't let me install it (Only Apache is allowed). Sorry for the inconvenience. I'll try to open a new bug on Apache bug list or mod_fcigd bug list if I find it : maybe they'll look into it.

The problem lies in php-cgi.exe.
I have been able to reproduce the problem on IIS 7.5.
In Fast-cgi the data is delivered using method similar to chunking.

In case of "Transfer-Encoding: chunked" IIS supplies Content-length:-1 in the request data, which is casted to uint in sapi_cgi_read_post. Causing the routine to read data until it has read the full 4G (2^32-1).
Also, both the methods sapi_cgi_read_post(cgi_main.c) and fcgi_read(fastcgi.c) try to read the complete buffer time after time, causing the end-marker (0-sized chunk) only to be seen when it would be at buffer-boundary. However the sapi_cgi_read_post funtion is called several times after the actual content has been read causing the fcgi_read method to block.
I expect similar cause to apply for apache.

Solution appears
1) do not loop in fcgi_read; this way when reading the final marker, it is returned to the calling code.
2) Set SG(request_info).content_length to SG(read_post_bytes) + read_bytes when tmp_read_bytes ==0 && SG(request_info).content_length == -1

@ andres at fenestrae dot com

Have you been able to try what you suggested in your last post ?

florian dot fernandez at navaho dot fr 

I have been able to try my solution in combination with 5.2.17.

See the patches in this topic for the exact code-changes I made.

Sorry, I didn't see it before. I'll give it a try with 5.4.0

Maybe I did something wrong but the patch doesn't seem to work with PHP 5.4.0 on Linux.

@florian dot fernandez at navaho dot fr

Florian,

I'm afraid i cannot help you any further on Linux.
The solution is not specific for Windows.
What I did to tackle the problem at first is to write a small program that ran instead of php-cgi which copied whatever it received on stdin to an other a mailslot.
This output I fed into php-cgi to reproduce an pinpoint the cause. 

Regards Andre

For Apache mod_fcgid, I have a patch available in the bug I filed at 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53332

Essentially, PHP is following the spec, and not reading beyond the FastCGI 
CONTENT_LENGTH header value - so correct fixes are necessarily above PHP, in the 
FastCGI or web server implementation.

at the end of the day, this is not a php bug

Well I am still facing this problem.
Any hints to solve this issue.

I am using fastcgi and php and trying to read the POST Data sent as transfer-encoding:chunked.

Appreciate any help

Hi,
Is there any solution to request with chunked encoding with php?
I observe that server is waiting indefinitely until client time-out and then process the packet with empty body.
I'm using php 7.2 and I think it still have this problem.

In a strict sense this is indeed not a PHP bug, because the CGI
specification (which is only informational, though), mandates[1]:

| As transfer-codings are not supported on the request-body, the
| server MUST remove any such codings from the message-body, and
| recalculate the CONTENT_LENGTH.  If this is not possible (for
| example, because of large buffering requirements), the server
| SHOULD reject the client request.

However, even though this is not done by IIS, its behavior still
appears to be reasonable, since it acknowledges the `Expect:
100-continue` header by immediately responding with `HTTP/1.1 100
Continue`, and then calls php-cgi.exe with CONTENT_LENGTH=-1 and
makes the full payload available on stdin.  So it seems the (F)CGI
SAPI *could* support chunked uploads in combination with IIS.

I have attached iis-cgi-chunked-poc as *PoC* for IIS and CGI only
(not FCGI).

[1] <https://tools.ietf.org/html/rfc3875#section-4.1.2>

Problem persists in Amazon Linux 2 distro.
PHP 7.2.34 FPM
Server version: Apache/2.4.46 ()

If I post a multipart/form-data with Content-Length defined it works, however if I post a multipart/form-data with Transfer-Encoding: chunked only, PHP doesn't get any of the _PÖST or _FILES variables.

-= WORKING =-

OST /upload.php HTTP/1.1
content-type: multipart/form-data; boundary=--------------------------657923799994993493862187
Host: 52.70.217.5
Content-Length: 2772
Connection: close

--c67c245a-C--
----------------------------657923799994993493862187^M
Content-Disposition: form-data; name="my_field"^M
^M
test^M
----------------------------657923799994993493862187^M
Content-Disposition: form-data; name="my_logo"; filename="logo.png"^M
Content-Type: image/png^M
^M
<89>PNG^M....

-=NOT WORKING=-
POST /upload.php?type=win HTTP/1.1
content-type: multipart/form-data; boundary=--------------------------701658193841349554663905
Host: 52.70.217.5
Connection: close
Transfer-Encoding: chunked

--486c8a2a-C--
----------------------------701658193841349554663905^M
Content-Disposition: form-data; name="my_field"^M
^M
test^M
----------------------------701658193841349554663905^M
Content-Disposition: form-data; name="my_logo"; filename="logo.png"^M
Content-Type: image/png^M
^M
<89>PNG^M...

@ribarra

Apache's bug for this is here https://bz.apache.org/bugzilla/show_bug.cgi?id=57087 and has apparently been fixed in Apache/2.4.47!  Not had chance to test it yet.