From:
Operating system: CentOS 4.8
PHP version: 5.3SVN-2010-05-09 (snap)
Package: SOAP related
Bug Type: Bug
Bug description:Chunked response parsing error
Description:
------------
I was getting an error from a SoapClient call: "Error Fetching http body,
No Content-Length, connection closed or chunked data". Thing was I
couldn't see any problem with the HTTP response.
I tracked the problem down to the get_http_body function in
ext/soap/php_http.c, where it reads the chunk size using php_stream_gets().
That's returning the chunk size plus the CR (0d) but leaving the LF (0a)
unread. Then the unread LF gets read with HTTP chunk, and the attempt to
read the next chunk size starts with the last character of the HTTP chunk,
since it's behind one thanks to the unread LF.
Here's a chunk of the response that throws it off, with the chunk size
(000001bc) in the middle, surrounded by CR/LF pairs.
00000850 3b 20 63 68 61 72 73 65 74 3d 22 75 74 66 2d 38 |;
charset="utf-8|
00000860 22 0d 0a 0d 0a 30 30 30 30 30 31 62 63 0d 0a 3c
|"....000001bc..<|
00000870 65 6e 76 3a 45 6e 76 65 6c 6f 70 65 20 78 6d 6c |env:Envelope
xml|
I added a little code under the line that adjusts the http buffer
allocation, and above the loop that reads the chunk, and this solved the
problem for me:
ch = php_stream_getc(stream); /* php_stream_gets may stop after CR and
leave LF in the buffer. If so, we need to eat it. */
if (ch != '\n') {
// Nope, it wasn't a LF. Put it at the start of the current buffer,
and advance one character.
http_buf[http_buf_size] = ch;
len_size++;
http_buf_size++;
}
This reads the next character, and if it is an LF it eats it, and if it
isn't it adds it to the http buffer.
I wanted to run this by someone more experienced hacking on the php source
before going any further to make sure the bug is legit, and the fix looks
at all sane.
--
Edit bug report at http://bugs.php.net/bug.php?id=51775&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51775&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51775&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51775&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51775&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51775&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51775&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51775&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51775&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51775&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51775&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51775&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51775&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51775&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51775&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51775&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=51775&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51775&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51775&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51775&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51775&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51775&r=mysqlcfg
