I'm seeing 4 to 5 warnings on my status report page, like "The web servers configuration will need to be adjusted. The server should have responded with a 304, instead a 404 was returned.", as shown in the screenshot.
I use Drupal 7, Nginx, advagg 7.x-2.17 and httprl. Standard Nginx configuration from https://github.com/perusio/drupal-with-nginx with minor adjustments (e.g., customized public path).
Here is how I debugged the issue:
When running following Drush command to simulate/track HTTP calls,
drush php-eval 'module_load_include("install", "advagg", "advagg");advagg_requirements("runtime");'
, I found following records in my Nginx log:
[17:04:46] "GET /sites/a.com/files/advagg_css/css__1452301485.css HTTP/1.0" 404 4080
[17:04:46] "GET /sites/a.com/files/advagg_js/js__1452301485.js HTTP/1.0" 404 4080
[17:04:46] "GET /sites/a.com/files/advagg_css/css__1.css HTTP/1.0" 200 23291
[17:04:46] "GET /sites/a.com/files/advagg_css/sites/a.com/files/advagg_css/css__1.css HTTP/1.0" 404 162
[17:04:46] "GET /sites/a.com/files/advagg_css/css__1.css HTTP/1.1" 200 6982
[17:04:46] "GET /sites/a.com/files/advagg_css/sites/a.com/files/advagg_css/css__1.css HTTP/1.1" 404 136
[17:04:46] "GET /sites/a.com/files/advagg_js/js__2.js HTTP/1.0" 200 3400
[17:04:46] "GET /sites/a.com/files/advagg_js/sites/a.com/files/advagg_js/js__2.js HTTP/1.0" 404 162
[17:04:46] "GET /sites/a.com/files/advagg_js/sites/a.com/files/advagg_js/js__2.js HTTP/1.0" 404 162
[17:04:46] "GET /sites/a.com/files/advagg_js/js__2.js HTTP/1.1" 200 1188
[17:04:46] "GET /sites/a.com/files/advagg_js/sites/a.com/files/advagg_js/js__2.js HTTP/1.1" 404 136
[17:04:46] "GET /sites/a.com/files/advagg_js/sites/a.com/files/advagg_js/js__2.js HTTP/1.1" 404 136
(NOTE: I've cleaned up the logs making them shorter and clearer.)
If we just read the last 3 lines: First it made an HTTP request to an advagg JS file, with HTTP 200 returned; then made an HTTP request to an advagg JS file with incorrect URL being used (path public:// being used twice to generate the URL), causing an HTTP 404 returned.
My question is: how could the wrong URL "/sites/a.com/files/advagg_js/sites/a.com/files/advagg_js/js__2.js" being created? Has anyone seen anything like this before? I'm wondering if it's a configuration issue or a coding issue.
Thanks
Comment | File | Size | Author |
---|---|---|---|
#27 | advagg-2647144-25-update-readme.patch | 19.41 KB | mikeytown2 |
#12 | Screen Shot 2016-01-12 at 3.49.00 PM.png | 145.81 KB | deminy |
#11 | advagg-2647144-10-fix-double-encode.patch | 1.47 KB | mikeytown2 |
Screen Shot 2016-01-08 at 5.05.22 PM.png | 261.58 KB | deminy |
Comments
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedLooks 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.
Comment #3
dimon00 CreditAttribution: dimon00 commentedSame configuration:
Drupal 7, Nginx, advagg 7.x-2.17 and httprl
same error.
I add I'm on https.
Regards
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commentedIs 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]);'
Comment #5
deminyOnly the first two requests are ""js__$TIMESTAMP.js" files; the rest are all "js__-so9_-GCk165815N_ym54k4z1cK6jKpChLOuXC1kO58__SgMOIYjhipumaF_bGbiWLQL2vw_qjqI6ulM02gNeCo4__T5QKUgDU4661vEL1Rhnc4VoezWjF_OEIrNP-nIz0UI8.js" style requests.
Command:
Output:
public://advagg_css public://advagg_js
Command:
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:
http://a.com/sites/a.com/files/advagg_css http://a.com/sites/a.com/files/advagg_js
Thanks
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedAnd 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]);'
Comment #7
deminy@mikeytown2, I updated my previous post with additional answers. Please check.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedOutput of this?
drush php-eval 'echo variable_get("file_public_path", conf_path() . "/files") . " " . file_create_url("public://");'
Comment #9
deminyCommand:
drush php-eval 'echo variable_get("file_public_path", conf_path() . "/files") . " " . file_create_url("public://") . "\n";'
Output:
sites/a.com/files http://a.com/sites/a.com/files/
Command:
drush vget file_public_path
Output:
file_public_path: sites/a.com/files
Comment #11
mikeytown2 CreditAttribution: mikeytown2 commentedI think this will fix the reported issue. Please re-open if this is still not fixed.
Comment #12
deminyThanks for the patch; now another issue raised on status report page: "The web servers configuration will need to be adjusted. The server should have responded with a 304, instead a 200 was returned."
When running following Drush command to simulate/track HTTP calls,
drush php-eval 'module_load_include("install", "advagg", "advagg");advagg_requirements("runtime");'
, I found following records in my Nginx log:
Screenshot of Status Report page attached.
Comment #13
deminyComment #14
deminyIt could be just a Nginx configuration issue. I might need to double check my Nginx configurations. Will post an update if I find something.
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commentedCan 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"; }'
Comment #16
deminy2nd execution outputs "no last-modified". I assume it should be an Nginx configuration issue. Will post an update next few days once I find something.
Comment #17
mikeytown2 CreditAttribution: mikeytown2 commentedhttp://cgit.drupalcode.org/advagg/tree/README.txt#n480
Comment #18
deminyThanks mikeytown2. I've played with advagg-suggested configurations ( http://cgit.drupalcode.org/advagg/tree/README.txt#n480 ) and configurations from https://github.com/perusio/drupal-with-nginx; also tried to disable/enable httprl, use different advagg/httprl configurations, use localhost instead of server name (different IP) when making requests, etc. However, I still can't get HTTP 304 responses back (I don't use proxy servers).
I will try to dig more into it by myself first, and will let you know if I find anything or need any help from you.
Comment #19
mikeytown2 CreditAttribution: mikeytown2 commentedexpires max;
is what allows for the last-modified header to work.Comment #20
mikeytown2 CreditAttribution: mikeytown2 commentedIs there a
add_header Last-Modified "";
anywhere in your configuration? You can also try addingetag on
and removingadd_header ETag "";
.Comment #21
mikeytown2 CreditAttribution: mikeytown2 commentedMoving this to a support request as that seems to be the direction that this issue has taken.
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commented@deminy: Removing the
add_header Last-Modified 'Wed, 20 Jan 1988 04:20:42 GMT';
tag from perusio's config solves the HTTP 200 issue with AdvAgg.Comment #23
Shane Birley CreditAttribution: Shane Birley commentedI 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?
Comment #24
mikeytown2 CreditAttribution: mikeytown2 commented@Shane Birley
Try removing httprl instead of advagg.
Code that might be related inside advagg.install
Comment #25
Shane Birley CreditAttribution: Shane Birley commentedAh 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.
Comment #27
mikeytown2 CreditAttribution: mikeytown2 commentedGoing 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.