As topic says. Additional I get Error opening socket ssl:// and core gives Not Found

function httprl_admin_settings_form() {
$headers = array();
$headers['User-Agent'] = 'User-Agent: Drupal (+';
// Add in the headers and enable blocking mode.
$options = array(
'blocking' => TRUE,
'headers' => $headers,
'method' => 'HEAD',
'max_redirects' => 1,
$urls = array(
  foreach (
$urls as $url) {
// Queue up the requests.
httprl_request($url, $options);
// Compare to core:
krumo(drupal_http_request($url, $options));
// Execute requests.
$responses = httprl_send_request();
  foreach (
$responses as $response) {


Title:redirect_code/redirect_url are an arrays, not like core single valuesredirect_code/redirect_url are arrays, not single values like core (expected)

Category:bug» feature
Priority:Critical» Normal

Because multiple requests are going on, I need the redirect arrays to keep track of who requested what. This additional information could be removed at the end, but I figured it might be useful so I kept it. If having the redirect being an array is a major issue (I'll need more then it doesn't exactly do what core does) I'll look at some options. You can use array_pop to get the same info currently.

As for Error opening socket ssl:// I can not repo that on my home computer (Win XP running XAMPP) using the latest checked in HTTPRL code.

I'm still able to repro with XAMPP on Win7.

The reason seems to be an invalid certificate on the remote site. WGET also complains that it's not able to validate the certificate. Not sure why core does not show this error... in the 302 redirect show the error - directly. WGET complains and say it's a self-signed certificate and I could skip the errors with --no-check-certificate.

wget -d

About array of redirect codes. The httprl homepage says it's API compatible to core. This also means the result array. I have no problem with the extra stuff you added as I do not need this, but if the content of the result has other structure, I need many conditional stuff to workaround the inconsistencies. I was happy that the module is named "API compatible" and expected that is really is... my code checks for and compares the value of $response->redirect_code and this fails if there is a subarray. I also see some benefits for the array, but it shouldn't be the default.

I'm also running the max_redirects with 1 only to get the first redirect code. I have seen so many buggy sites that do a 302, 302 and than a 301... If I would just use the last I may end up in very heavy troubles. This redirects may be invalid, but they could also be correct and the user must review manually as a temp redirect (302) may not need any link update in the content, where a 301 really requires an update. Some sites have really strange logics e.g. you look for and they redirect with 302 to

Maybe a bug of core...

new144.19 KB


Ah, no CORE IS correct. I compared it with Google Chrome and the page output. They show a 404 page on their site...

I know the certificate tree university's, the DFN and this tree should be fairly "new" in browsers... and I guess my wget/xampp do not have the latest certificate authories in their store like Google Chrome and Your xampp has. I guess you can repro this with any self-signed certificate that your computer do not trust... I really wonder why core has other results like stream wrappers in the *same* PHP install...

I'm using xampp Lite 1.7.3

What version of PHP are you using?

I'm running php 5.2.9 (xampp 1.7.1)

This error is below what I can control. Both HTTPRL and drupal_http_request() use stream_socket_client(); main issue being the STREAM_CLIENT_ASYNC_CONNECT flag (what HTTPRL sets).

PHP 5.3.1

Status:Active» Needs review
new1.51 KB

So what I can do is if we tried to connect with the STREAM_CLIENT_ASYNC_CONNECT and it failed; we can use the normal way. Make this an option? Please review the attached patch and see if it works for you.

Status:Needs review» Reviewed & tested by the community
new31.99 KB

Looks good to me now.

Note: I'm using 5.3.1... Your documentation about the versions it's fixed in - is wrong, but I also have no idea what PHP 5.3.x version contains a fix for this PHP bug.

Aside it may be a good idea to do one test with a self-signed cert... just to be save. It's one of these cases I have not really tested.


Status:Reviewed & tested by the community» Fixed

patch in #10 has been committed. If you want to find the 5.3.x version where this is fixed that would be helpful; otherwise I'll let this go as I do reference the bug in the code.

Status:Fixed» Needs work

How about the redirect arrays? Can we make that optional?

Status:Needs work» Needs review
new968 bytes

I'll have both in the response object. Here's a patch that does this.

Code wise this looks like a good solution. I need to test it later.

Status:Needs review» Fixed
new944 bytes

This patch has been committed. It's an object not an array.

Why are you not using the redirect_url_array for the working job and just set the redirect_url on the end... Just an idea for code refactoring/logic cleanup.

I'll do the refactoring work when I get around to implementing #1427958: Run callback after stream has been fetched. This will require a non trivial change to the event loop and will require a fair bit of refactoring to accomplish non blocking callbacks. While in here I'll clean up the redirect code.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes