php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33164 soap ext incorrect check of HTTP_1_1
Submitted: 2005-05-27 16:26 UTC Modified: 2005-05-31 01:46 UTC
From: abuttner at mitre dot org Assigned: dmitry
Status: Closed Package: SOAP related
PHP Version: 5.0.4 OS:
Private report: No CVE-ID:
 [2005-05-27 16:26 UTC] abuttner at mitre dot org
Description:
------------
I am getting an error that is similar to BUG #30329 (Error Fetching http body, No Content-Length, connection closed or chunked data).  The fix for this bug was included in PHP 5.03, I am using PHP 5.04.

my error message:

PHP Fatal error: Uncaught SoapFault exception: [HTTP] Error Fetching http body, No Content-Length, connection closed or chunked data in ...

In short, I think the error is in PHP and how it is handling the response from the proxy.  (no error when not using a proxy)  My client code is making a request through a proxy to a web service.  The web service is getting the request and producing the intended response.  Unfortunately, the HTTP headers of this response are getting changed by the proxy server and causing PHP to fail due to an unexpected header.
 
The proxy server is reporting itself as 'squid 2.5.STABLE7'.  Looks like this version was released in Oct and the latest version is 2.5.STABLE10.  The proxy server is rewriting the HTTP/1.1 headers from Sun AppServer 7 that uses "Connection: close", to HTTP/1.0 using "Proxy-Connection: close".  (I'm not an HTTP Header guy, so is the proxy server handling HTTP headers correctly?)

The error in PHP is occuring in the source file php_http.c due to the function get_http_body() returning FALSE.  The fix for bug #30329 added a parameter 'close' to this function and used this paremeter to determine whether to look for a "Connection: close" in the HTTP header.  Again, not being an HTTP header guy, I assume that with 1.0 header, you can't trust that a "Connection: close" header will be present, as that is why the fix does what it does.

When get_http_body() is called, the value !http_1_1 is used for the 'close' parameter.  The value of http_1_1 is supposed to be 0 if HTTP/1.0 and 1 if HTTP/1.1.  Following it through, the "Connection: close" header will be checked if HTTP/1.1 is being used.

** BUG **

There is a bug in line 688 of the 5.0.4 release.  I'm sure the line number is off in the latest CVS version.  I did look at the web based CVS repository and the line of code has not been changed.  Unfortunately, line breaks weren't happening and so line numbers were unavailable.

if (strncmp(http_version,"1.1", 3)) {

What is happening is that the value of http_version is "1.0" and the strncmp is returning -1.  This causes the if block to be executed when it shouldn't.  Was is intened is:

if (strncmp(http_version,"1.1", 3) == 0) {

which will only execute the if block when http_version equals "1.1".

Thanks
Drew

Reproduce code:
---------------
char* http_version = "1.0";

int main(int argc, char* argv[])
{

	if (strncmp(http_version,"1.1", 3)) {
		printf("version = 1.1\n");
	}
	else
	{
		printf("version = 1.0\n");
	}
	return 0;
}

Expected result:
----------------
version = 1.0

Actual result:
--------------
version = 1.1

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-05-31 01:46 UTC] iliaa@php.net
This bug has been fixed in CVS.

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.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Wed Apr 23 14:02:33 2014 UTC