|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58240 st->errorbuffer not cleared between uses of persistent handles
Submitted: 2008-06-19 04:33 UTC Modified: 2008-07-12 15:05 UTC
From: derrick at pallas dot us Assigned: mike (profile)
Status: Closed Package: pecl_http (PECL)
PHP Version: 5.1.6 OS: Centos 5
Private report: No CVE-ID: None
 [2008-06-19 04:33 UTC] derrick at pallas dot us
In http_request_api.c, st->errorbuffer is cleared in _http_request_reset but not in _http_request_defaults. The problem is that when a handle is acquired from the persistent pool in _http_curl_init_ex via http_persistent_handle_acquire, _http_request_defaults is called. Thus, if the acquired handle has been used before and an error was written to st->errorbuffer, it persists. That means that the return value of HttpRequest::getRequestInfo("error") may not apply to the current request.

Reproduce code:

diff -ubr pecl_http-1.6.0/http_request_api.c pecl_http-1.6.0p/http_request_api.c
--- pecl_http-1.6.0/http_request_api.c  2007-11-26 06:54:40.000000000 -0800
+++ pecl_http-1.6.0p/http_request_api.c 2008-06-19 01:25:45.000000000 -0700
@@ -520,6 +520,12 @@
                HTTP_CURL_OPT(CURLOPT_POST, 0L);
                HTTP_CURL_OPT(CURLOPT_UPLOAD, 0L);
+               http_request_storage *st =
+                 http_request_storage_get(request->ch);
+               if ( st && st->errorbuffer )
+                          st->errorbuffer[0] = '\0';
 /* }}} */

To reproduce:

  $request = null;
    $request = new HttpRequest( $_GET["url"] );
  catch ( Exception $exception ) { /* eat */ }

  if ( $error = $request->getResponseInfo("error") )
    die( $error );
No problems!

Expected result:
Given that the script above is at /test.php,

Hit <>. The response should be "No problems!"

Hit <>. The response should be similar to "Couldn't resolve host 'example.tld'"

Now hit <>. The response should be "No problems!"

Actual result:
If the "example.tld" request used a persistent handle and this second request gets it, you'll see the error message instead.

Since this happens on a per-process, inter-thread basis, it's easier to catch if web-server is configured to only launch a single FastCGI PHP. (One-off CGIs and CLIs should not be affected.)

It's also much easier to see this problem if http.persistent.handles.limit=1, but not strictly necessary.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-12 15:05 UTC]
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on

In case this was a website problem, the change will show
up on the website in short time.
Thank you for the report, and for helping us make PECL better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed May 22 22:01:32 2024 UTC