ID: 49014 Updated by: [email protected] Reported By: andreas dot streichardt at globalpark dot com -Status: Open +Status: Closed Bug Type: Streams related Operating System: Linux PHP Version: 5.3.0 New Comment:
This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2009-07-23 12:18:41] [email protected] Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=284646 Log: Fixed bug #49014 (dechunked filter broken when serving more than 8192 bytes in a chunk) # Original patch by andreas dot streichardt at globalpark dot com ------------------------------------------------------------------------ [2009-07-22 15:40:49] andreas dot streichardt at globalpark dot com doesn't help. Maybe i should have posted a little bit more about which content is right and which content is wrong ;) For me the snap returns: string(8199) "1234567890[...]012345678901234565 00000 0 " size and content is wrong. The last 5 and the separate 0 shouldn't even be there and indicate that decoding has completely failed (see the end of the $streams[] stuff. These are chunk markers and should have been decoded. The correct output would be (which works with my hacked php 5.3): string(16005) "1234567890[...]123456789000000" If you are getting the correct output without my patch your php is probably using a higher internal read buffer (mine is 8192 bytes - no idea if you can set that or if it is different on different platforms). As said in the bug description. This bug only appears if the string is bigger than this buffer.) ------------------------------------------------------------------------ [2009-07-22 12:16:51] [email protected] Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Seems to work fine in latest SVN. ------------------------------------------------------------------------ [2009-07-22 10:09:59] andreas dot streichardt at globalpark dot com --- php-5.3.0/ext/standard/filters.c 2009-04-16 12:16:27.000000000 +0200 +++ php-5.3.0-modified/ext/standard/filters.c 2009-07-22 11:41:26.417443070 +0200 @@ -2008,6 +2008,7 @@ } data->chunk_size -= end - p; out_len += end - p; + data->state=CHUNK_BODY; return out_len; } case CHUNK_BODY_CR:) ------------------------------------------------------------------------ [2009-07-22 10:07:45] andreas dot streichardt at globalpark dot com Description: ------------ The dechunked filter is broken when the webserver is serving more than 8192 bytes in a chunk. When it reenters the function to read from the buffer the function thinks a new chunk is coming along although the chunk is not yet read up to the end and thinks the chunk is broken. I made a quick test and Apache seems to always serve 8192 bytes in a chunk. However lighttpd for example serves much more. So reading HTTP/1.1 streams with Transfer-Encoding: chunked is always broken on larger documents. The situation i had was that i were serving a larger wsdl over PHP (which serves documents with Transfer-Encoding: chunked). This is probably related to this bug (which i originally hit): http://bugs.php.net/bug.php?id=47021 The reason why this affects SOAP is because the default mechanism to fetch wsdl files changed in PHP 5.3. In PHP 5.2 it fetched documents using HTTP 1.0. Now it is HTTP 1.1. The attached patch fixes this. Reproduce code: --------------- $length=1600; $streams[]="data://text/plain,".dechex($length*10)."\r\n".str_repeat("1234567890",$length)."\r\n5\r\n00000\r\n0\r\n"; foreach ($streams as $name) { $fp = fopen($name, "r"); stream_filter_append($fp, "dechunk", STREAM_FILTER_READ); var_dump(stream_get_contents($fp)); fclose($fp); } Expected result: ---------------- Too much to post here and should be obvious Actual result: -------------- Some broken string (smaller than expected and thus wrong) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=49014&edit=1
