HTTP Requests Made to Incorrect URIs On Status Report Page

Looks like some requests are hitting the correct path "/sites/a.com/files/advagg_css/" while others seem to be doubled like "/sites/a.com/files/advagg_css/sites/a.com/files/advagg_css/"

Looking over the code and it appears that file_create_url() gets called twice while checking out 304s so that could be the cause. Will check this out more next week.

Same configuration:
Drupal 7, Nginx, advagg 7.x-2.17 and httprl
same error.
I add I'm on https.

Regards

Is the actual file being requested "js__2.js" or is it "js__$TIMESTAMP.js" or "js__-so9_-GCk165815N_ym54k4z1cK6jKpChLOuXC1kO58__SgMOIYjhipumaF_bGbiWLQL2vw_qjqI6ulM02gNeCo4__T5QKUgDU4661vEL1Rhnc4VoezWjF_OEIrNP-nIz0UI8.js"

This key bit of information will help me narrow down what part of the code I need to look at.

Also what does this output?
drush php-eval 'list($css_path, $js_path) = advagg_get_root_files_dir(); echo file_create_url($css_path[0]) . " " . file_create_url($js_path[0]);'

And what about when it's wrapped in file_create_url?

drush php-eval 'list($css_path, $js_path) = advagg_get_root_files_dir(); echo file_create_url($css_path[0]) . " " . file_create_url($js_path[0]);'

Output of this?
drush php-eval 'echo variable_get("file_public_path", conf_path() . "/files") . " " . file_create_url("public://");'

I think this will fix the reported issue. Please re-open if this is still not fixed.

Can you run this?

drush php-eval 'module_load_include("install", "advagg"); list($css_path) = advagg_get_root_files_dir(); $filename = advagg_install_get_first_advagg_file($file_path, "css"); $url = file_create_url($css_path[0] . "/" . $filename); $options = array("headers" => array("Accept-Encoding" => "gzip, deflate",),"version" =>"1.0"); advagg_install_url_mod($url, $options, FALSE); $request = drupal_http_request($url, $options); if (isset($request->headers["last-modified"])) { $if_modified_options = $options; $if_modified_options["headers"] = array("Accept-Encoding" => "gzip, deflate","If-Modified-Since" => $request->headers["last-modified"]); advagg_install_url_mod($url, $if_modified_options, FALSE); $request_304 = drupal_http_request($url, $if_modified_options); if ($request_304->code == 304) { echo $request_304->status_message;} else { print_r($request_304);} } else { echo "no last-modified"; }'

http://cgit.drupalcode.org/advagg/tree/README.txt#n480

expires max; is what allows for the last-modified header to work.

Is there a add_header Last-Modified ""; anywhere in your configuration? You can also try adding etag on and removing add_header ETag "";.

Moving this to a support request as that seems to be the direction that this issue has taken.

I am not sure if this is related but around mid-December, I started seeing HTTP 0 statuses happening. I have been unable to update module status, unable to install new modules through the web UI, etc.

I am finally getting around to testing today and in every instance, if I remove AdvAgg, the problem goes away. No errors are being tossed, nothing in the server logs -- Drupal just says: HTTP 0. Boom.

I thought I would look here and make a report about what I have been seeing but this might be the same issue just in a different way?

@Shane Birley
Try removing httprl instead of advagg.

Code that might be related inside advagg.install

    if (defined('VERSION') && floatval(VERSION) >= 7.22 && is_callable('httprl_override_core')) {
      $old = variable_get('drupal_http_request_function', FALSE);
      $GLOBALS['conf']['drupal_http_request_function'] = 'httprl_override_core';

      // Only test 1.1; 1.0 is rarely used these days.
      $requirements = $old_requirements;

      $options['version'] = '1.1';
      advagg_install_chk_urls($requirements, $urls, $options, $mod_url, $type, $url_path, $file_path, $filename);

      $GLOBALS['conf']['drupal_http_request_function'] = $old;
    }

Ah ha. HTTPRL appears to be the culprit as I use it on almost everything. I will update and test it on the latest HTTPRL dev to confirm.

*UPDATE*

Confirmed. HTTPRL is the problem. Both latest dev and current release.

Going to mark this issue as fixed. I've added a note in the nginx config section due to what was said in #22. Also fixed some markdown formatting issues.