php.net |  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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: derrick at pallas dot us
New email:
PHP Version: OS:

 

 [2008-06-19 04:33 UTC] derrick at pallas dot us
Description:
------------
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:
---------------
Patch:

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_CURL_OPT(CURLOPT_HTTPGET, 1L);
+
+               http_request_storage *st =
+                 http_request_storage_get(request->ch);
+
+               if ( st && st->errorbuffer )
+                          st->errorbuffer[0] = '\0';
        }
 }
 /* }}} */


To reproduce:

<?php
  $request = null;
  try
  {
    $request = new HttpRequest( $_GET["url"] );
    $request->send();
  }
  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 <http://example.com/test.php?url=http%3A%2F%2Fexample.com%2F>. The response should be "No problems!"

Hit <http://example.com/test.php?url=http%3A%2F%2Fexample.tld%2F>. The response should be similar to "Couldn't resolve host 'example.tld'"

Now hit <http://example.com/test.php?url=http%3A%2F%2Fexample.com%2F>. The response should be "No problems!"

Actual result:
--------------
If the "example.tld" request used a persistent handle and this second example.com 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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-12 15:05 UTC] mike@php.net
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 pecl.php.net.

In case this was a pecl.php.net 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-2021 The PHP Group
All rights reserved.
Last updated: Wed Oct 20 05:03:33 2021 UTC