Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.6.0

Bug #18331 Add warning raised by stream_socket_client() to exception message
Submitted: 2011-03-03 02:48 UTC
From: flack Assigned: avb
Status: Closed Package: HTTP_Request2 (version 2.0.0beta1)
PHP Version: 5.2.4 OS: Debian 5
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 40 - 7 = ?

 
 [2011-03-03 02:48 UTC] flack (Andreas Flack)
Description: ------------ The test script below throws an exception with a wrong URL in the message, e.g. I enter 'https:://test.com' and the exception message says 'ssl://test.com:443'. The same code works fine with a http URL Test script: --------------- $params = array ( 'connect_timeout' => 15, 'timeout' => 30, ); $uri = 'https://www.mydomain.com'; $c = new HTTP_Request2($uri, HTTP_Request2::METHOD_POST, $params); $variables = array('test' => array('a', 'b'), 'test2' => 2); foreach ($variables as $name => $value) { $c->addPostParameter($name, $value); } try { $response = $c->send(); } catch (Exception $e) { var_dump($e->getMessage()); } Actual result: -------------- Unable to connect to ssl://www-mydomain.com:443. Error:

Comments

 [2011-03-03 03:01 UTC] avb (Alexey Borzov)
-Status: Open +Status: Bogus
The URL is not wrong, it just shows the actual $remote_socket parameter passed to stream_socket_client(), so that *you* could debug the problem more easily. The strange thing is missing error message after that. Perhaps there are some issues with SSL in your PHP setup that prevent it from working altogether and even returning meaningful errors.
 [2011-03-03 15:25 UTC] flack (Andreas Flack)
-Summary: POST requests to HTTPS URLs throw exception +Summary: POST requests to HTTPS URLs with self-signed certificates throw exception -Status: Bogus +Status: Open
I did some debugging and by removing the @ sign in Request2/Adapter/Socket.php on line 321 I got the following output: Warning: stream_socket_client() [function.stream-socket-client]: SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in /usr/share/php/HTTP/Request2/Adapter/Socket.php on line 321 So the cause of the problem is apparaently that this is a self-signed certificate. I still think this is a bug/regresion in HTTP_Request2, though, because when I do the same query on the same server with the old HTTP_Request packge, everything works fine.
 [2011-03-03 16:05 UTC] avb (Alexey Borzov)
-Status: Open +Status: Bogus
That's not a "regression", that's documented behaviour: http://pear.php.net/manual/en/package.http.http-request2.config.php > ssl_verify_peer Whether to verify peer's SSL certificate. Note that this is on by default, to follow the behaviour of modern browsers and current cURL version.
 [2011-03-03 16:22 UTC] flack (Andreas Flack)
OK, fair enough. So I added ssl_verify_peer = false to my options and now it works again. However, there is still the problem that the errstr and errno variables don't get populated correctly. It would be good if this issue could be fixed or worked around somehow, because right now, the only way to find out why your request failed is to mess around with the HTTP_Request2 source code.
 [2011-03-03 21:07 UTC] avb (Alexey Borzov)
-Summary: POST requests to HTTPS URLs with self-signed certificates throw exception +Summary: Add warning raised by stream_socket_client() to exception message -Status: Bogus +Status: Assigned -Assigned To: +Assigned To: avb
Agree here, probably the same track_errors wrapper as used by fopen() may be added here. Empty exception message is definitely not useful.
 [2011-03-25 14:57 UTC] avb (Alexey Borzov)
-Status: Assigned +Status: Closed
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.