#33164 [NEW]: soap ext incorrect check of HTTP_1_1

From: abuttner at mitre dot org Operating system: PHP version: 5.0.4 PHP Bug Type: SOAP related Bug description: soap ext incorrect check of HTTP_1_1 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 -- Edit bug report at http://bugs.php.net/?id=33164&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33164&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33164&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33164&r=trysnapshot51 Fixed in CVS: http://bugs.php.net/fix.php?id=33164&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=33164&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33164&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33164&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33164&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33164&r=support Expected behavior: http://bugs.php.net/fix.php?id=33164&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33164&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33164&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=33164&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33164&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=33164&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33164&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33164&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33164&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33164&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33164&r=mysqlcfg