Home Original page

dechunked filter broken when serving more than 8192 bytes in a chunk

Bug #49014 dechunked filter broken when serving more than 8192 bytes in a chunk
Submitted: 2009-07-22 10:07 UTC Modified: 2009-07-23 12:19 UTC
From: andreas dot streichardt at globalpark dot com Assigned:
Status: Closed Package: Streams related
PHP Version: 5.3.0 OS: Linux
Private report: No CVE-ID: None

 [2009-07-22 10:07 UTC] 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)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2009-07-22 10:09 UTC] 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 15:40 UTC] 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-23 12:19 UTC] iliaa@php.net

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.