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.