Notice: Undefined property: stdClass::$redirect_code in httprl_send_request() (line 523 of \drupal7\sites\all\modules\httprl\httprl.module).
Warning: fwrite(): 696 is not a valid stream resource in httprl_send_request() (line 469 of \drupal7\sites\all\modules\httprl\httprl.module).
Warning: fclose(): 696 is not a valid stream resource in httprl_send_request() (line 483 of \drupal7\sites\all\modules\httprl\httprl.module).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hass’s picture

Title: Notices/Warnings: Undefined property/fwrite()/fclose() » Logic is broken with redirects
mikeytown2’s picture

The fclose() call can be silenced (@) because fwrite() failed. This patch does this and has been committed to 6.x & 7.x.

As for the warning; if you can create a way to reproduce it reliably that would be helpful. I wonder if stream_select()'s $except array would have any useful info when this happens.

The notice might be fixed with some of the other changes that went in today.

hass’s picture

Priority: Critical » Normal

Add this to your httprl.admin.inc and run the "admin/config/development/httprl" page...

NOTE: The Apple URL goes completely lost... the others have no status codes in responds array. I have tested with latest DEV.

function httprl_admin_settings_form() {

  $headers = array();
  $headers['User-Agent'] = 'User-Agent: Drupal (+http://drupal.org/)';

  // Add in the headers and enable blocking mode.
  $options = array(
    'blocking' => TRUE,
    'headers' => $headers,
    'method' => 'HEAD',
    'max_redirects' => 1,
  );

  // Queue up the requests.
  httprl_request('http://www.apple.com/qtactivex/qtplugin.cab', $options);

  // Execute requests.
  $responses = httprl_send_request();
  foreach ($responses as $response) {
    krumo($response);
  }

  // Compare to core:
  $foo = drupal_http_request('http://www.apple.com/qtactivex/qtplugin.cab', $options);
  krumo($foo);

 

Notice:

Notice: Undefined property: stdClass::$redirect_code in httprl_send_request() (line 539 of drupal7\sites\all\modules\httprl\httprl.module
hass’s picture

max_redirects counter in options array is pretty strange... maybe the source of the issues. With max_redirects = 1: empty array

hass’s picture

Please compare the results. If there are multiple redirects httprl shows them all in code and error subarrays, but core does only show the last status code and error.

hass’s picture

Priority: Normal » Critical

Critical for next release.

mikeytown2’s picture

I can repo the bug with your code. Thanks for reporting! I'll be going to bed though; its 2am here.

mikeytown2’s picture

Priority: Critical » Normal
Status: Active » Fixed
FileSize
3.74 KB

This patch has been committed. Thanks for taking the time to get this right!

mikeytown2’s picture

Priority: Normal » Critical
hass’s picture

Status: Fixed » Active

The bug with 'http://www.apple.com/qtactivex/qtplugin.cab' is not fixed at all. My debugging shows that it tries 2 redirects and then it stops processing with 'maximum allowed redirects exhausted'.

This is incorrect behavior. As you can see in the options array I have defined 'max_redirects' => 1. This must cause httprl to STOP processing after the first redirect and give me the first returned redirect code in the responds array. It's not allowed to follow more redirects and it is not correct to tell me 'maximum allowed redirects exhausted'. Compare to core, please.

hass’s picture

Version: 7.x-1.x-dev » 7.x-1.4
Priority: Normal » Critical
hass’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

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