I have IIS 7 running with a PHP 5.3.8 web service. I have create a handler for PUT requests and when a PUT is attempted, the handler is called fine.
To access the PUT data sent by the client, I use code like
if (($stream = fopen('php://input', "r")) !== FALSE) {
fputs($logfile, "stream reading begin
");
stream_set_timeout($stream, 5);
$newcontent = "";
while ($chunk = fread($stream, 32)) {
$newcontent .= $chunk;
fputs($logfile, "stream read chunk >>$chunk<<
");
}
// $newcontent = (stream_get_contents($stream));
fputs($logfile, "stream read
");
The issue i ran into is, that the PHP script handling the PUT request hangs when reading the data. I started with "$newcontent = (stream_get_contents($stream));" which hangs. I then tried to set a timeout for the stream, no change. I then tried the while loop which reads the POST data in small chunks and logs them. This way I can see that almost the whole PUT data is read, but one of the read-requests towards the end (a few hundred bytes before the end of the data) never returns.
Following some posts I found on stackoverflow, I tried different application pool types, such as "classic .net" - no change.
I run PHP with FastCGI-
In IIS appcmd, I can see that these requests hang forever:
C:\Windows\System32\inetsrv>appcmd list requests /elapsed:3000
REQUEST "c400000080000e95" (url:PUT /.../.../....php?mac=009033280075&proc=&mode=flashdir&tag=phone-calls, time:729928 msec, client:172.16.10.131, stage:ExecuteRequestHandler, module:FastCgiModule)
REQUEST "6900000180000d81" (url:PUT /.../.../u....php?mac=0090333000af&proc=reset&mode=xml&tag=phone-regs, time:453588 msec, client:172.16.4.59, stage:ExecuteRequestHandler, module:FastCgiModule)
When I wireshark the HTTP connection, I see that it is idle with regular TCP keep alives.
Needless to say, the code runs just fine with Apache.
Looks to me as if PHP does not recognize the end of the incoming data and waits for more data. However, even if so I do not understand why the stream timeout does not take effect.
Any idea how to fix that?
Thank you, Christoph
PS: I should add that the client is using chunked encoding for the PUT data:
PUT /moodle-debug/.../....php?mac=IP111-28-00-75... HTTP/1.1
User-Agent: innovaphone-IP111/110792
Transfer-Encoding: chunked
23
vars check 09c4c4ec6778cb3eb4aa63
ac0
# 11r1 dvl IP111[11.0792],
...
I found a note in https://bugs.php.net/bug.php?id=60826
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).
Which would explain this behaviour. The question then would be: is there a fix?