Problem:
Gzip is failing for js files and Gzip is failing for css files messages on status report
Environment:
--- HTTPS ---> Nginx Proxy (caching and ssl termination) --- HTTP ---> Nginx Web Server (where drupal lives)
Enabled Modules/Versions:
Drupal 7.39
AdvAgg 7.x-2.15+10-dev
HTTPRL 7.x-1.14+32-dev + patch (Allow to define a port - and some cleanup.)
cURL HTTP Request 7.x-1.7+1-dev
Tests:
- Upgraded to nginx to 1.8.1
- Upgrading php to version 5.6
- Quadruple checked nginx configurations
- Verified Gzip is working
Steps to gzip issue:
- Based on the issue Advagg hook_requirements() don't work if self-site not directly accessible, I have added "127.0.0.1 www.example.com" to my /etc/host file, and still get
Adv CSS/JS Agg - Self Request Failure HTTP loopback requests to this server are returning a non positive response code of -1004
(screenshot here) still shows on my report. - After I manually verified that AdvAgg is working correctly like report message suggests, I set
$conf['advagg_skip_404_check'] = TRUE;
in settings.php - After refreshing report page, I receive the gzip errors below. I believe it is very similar to the issueAdvAgg returning ssl error (maybe httprl related); however, the solution didn't seem very legitimate (SSL key doesn't seem like my issue here).
Solutions?
I have been facing this issue for months. Everything is working correctly I believe, but the messages still appear that gzip isn't working. I understand a proxy in front of the web server isn't the "standard" setup people use, but I can't believe more people aren't discussing this issue in the queue. Obviously a few people have had problems, but I just can't find what the ultimate solution is.
Gzip Errors:
<?php
Adv CSS/JS Agg - gzip Gzip is failing for js files.
The web servers configuration will need to be adjusted. In most cases make sure that the webroots .htaccess file still contains this section "Rules to correctly serve gzip compressed CSS and JS files". Certain default web server configurations (nginx) do not gzip HTTP/1.0 requests. If you are using cloudfront you will have to add metadata to the .gz files. There are some other options if using cloudfront. Raw request info:
stdClass Object
(
[url] => https://www.example.com/sites/default/files/advagg_js/js__-qHPladmzRueryQkmwKb-w4ks9IKc9yVFsoRTPpDsDg__Pdxq8G-W6pSmk1AtsMYHJXjIquhv1IgovWv65-U5Ins__F0Ufe602oWCDWrToV1ce2sMw2sD9TqU26OFJTFV2GCg.js
[status] => Connecting.
[code] => -1004
[chunk_size] => 1024
[data] => ...
[request] => GET /sites/default/files/advagg_js/js__-qHPladmzRueryQkmwKb-w4ks9IKc9yVFsoRTPpDsDg__Pdxq8G-W6pSmk1AtsMYHJXjIquhv1IgovWv65-U5Ins__F0Ufe602oWCDWrToV1ce2sMw2sD9TqU26OFJTFV2GCg.js HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: close
Referer: https://www.example.com/admin/reports/status
User-Agent: Drupal (+http://drupal.org/)
Host: www.example.com
[options] => Array
(
[headers] => Array
(
[Accept-Encoding] => gzip, deflate
[Connection] => close
[Referer] => https://www.example.com/admin/reports/status
[User-Agent] => Drupal (+http://drupal.org/)
[Host] => www.example.com
)
[version] => 1.1
[timeout] => 7.9835140705109
[dns_timeout] => 8
[connect_timeout] => 8
[ttfb_timeout] => 8
[method] => GET
[data] =>
[max_redirects] => 3
[context] => Resource id #2465
[secure_socket_transport] => ssl
[blocking] => 1
[referrer] =>
[domain_connections] => 2
[global_connections] => 128
[global_timeout] => 120
[chunk_size_read] => 32768
[chunk_size_write] => 1024
[async_connect] =>
[ping_db] => 20
)
[socket] => ssl://www.example.com:443
[flags] => 4
[uri] => Array
(
[scheme] => https
[host] => www.example.com
[path] => /sites/default/files/advagg_js/js__-qHPladmzRueryQkmwKb-w4ks9IKc9yVFsoRTPpDsDg__Pdxq8G-W6pSmk1AtsMYHJXjIquhv1IgovWv65-U5Ins__F0Ufe602oWCDWrToV1ce2sMw2sD9TqU26OFJTFV2GCg.js
)
[running_time] => 0.016485929489136
[fp] =>
[error] => Error initializing socket ssl://www.example.com:443.
)
Warning
Adv CSS/JS Agg - gzip Gzip is failing for css files.
The web servers configuration will need to be adjusted. In most cases make sure that the webroots .htaccess file still contains this section "Rules to correctly serve gzip compressed CSS and JS files". Certain default web server configurations (nginx) do not gzip HTTP/1.0 requests. If you are using cloudfront you will have to add metadata to the .gz files. There are some other options if using cloudfront. Raw request info:
stdClass Object
(
[url] => https://www.example.com/sites/default/files/advagg_css/css__7L4lYfs2kVfwdJjEWdExAFz0bHa1Gg4XFZUzM27Ys2Q__O7WhxWs8e1aqYKPlT7KRvkXfETNInx4_3Ez9L5LAtC4__F0Ufe602oWCDWrToV1ce2sMw2sD9TqU26OFJTFV2GCg.css
[status] => Connecting.
[code] => -1004
[chunk_size] => 1024
[data] => ...
[request] => GET /sites/default/files/advagg_css/css__7L4lYfs2kVfwdJjEWdExAFz0bHa1Gg4XFZUzM27Ys2Q__O7WhxWs8e1aqYKPlT7KRvkXfETNInx4_3Ez9L5LAtC4__F0Ufe602oWCDWrToV1ce2sMw2sD9TqU26OFJTFV2GCg.css HTTP/1.1
Accept-Encoding: gzip, deflate
Connection: close
Referer: https://www.example.com/admin/reports/status
User-Agent: Drupal (+http://drupal.org/)
Host: www.example.com
[options] => Array
(
[headers] => Array
(
[Accept-Encoding] => gzip, deflate
[Connection] => close
[Referer] => https://www.example.com/admin/reports/status
[User-Agent] => Drupal (+http://drupal.org/)
[Host] => www.example.com
)
[version] => 1.1
[timeout] => 7.9837899208069
[dns_timeout] => 8
[connect_timeout] => 8
[ttfb_timeout] => 8
[method] => GET
[data] =>
[max_redirects] => 3
[context] => Resource id #2456
[secure_socket_transport] => ssl
[blocking] => 1
[referrer] =>
[domain_connections] => 2
[global_connections] => 128
[global_timeout] => 120
[chunk_size_read] => 32768
[chunk_size_write] => 1024
[async_connect] =>
[ping_db] => 20
)
[socket] => ssl://www.example.com:443
[flags] => 4
[uri] => Array
(
[scheme] => https
[host] => www.example.com
[path] => /sites/default/files/advagg_css/css__7L4lYfs2kVfwdJjEWdExAFz0bHa1Gg4XFZUzM27Ys2Q__O7WhxWs8e1aqYKPlT7KRvkXfETNInx4_3Ez9L5LAtC4__F0Ufe602oWCDWrToV1ce2sMw2sD9TqU26OFJTFV2GCg.css
)
[running_time] => 0.016210079193115
[fp] =>
[error] => Error initializing socket ssl://www.example.com:443.
)
?>
Comment | File | Size | Author |
---|---|---|---|
#9 | advagg-2568381-8-skip-gzip-test-no-data.patch | 2.84 KB | mikeytown2 |
Comments
Comment #2
cthshabel CreditAttribution: cthshabel commentedComment #3
mikeytown2 CreditAttribution: mikeytown2 commented-1004 is a "Error initializing stream/socket" error; PHP returned this error after 16ms. AdvAgg is trying to check if the gzip header is there, but this is failing to get any data back. Thinking AdvAgg should throw a different error in this case and allow one to skip this check with a variable.
Comment #4
mikeytown2 CreditAttribution: mikeytown2 commentedProvide a link to http://checkgzipcompression.com/?url= where the url has been filled in.
Comment #5
cthshabel CreditAttribution: cthshabel commentedhttp://checkgzipcompression.com/?url=https%3A%2F%2Fwww.veuit.com
I checked this before too and the results were were 80% gzipped
Comment #6
cthshabel CreditAttribution: cthshabel commentedFYI... when I change the etc/host back to
127.0.0.1 www.example.com
the results showed[code] => -111
which looks like it means "Connection refused". And still the same gzip errorsComment #7
cthshabel CreditAttribution: cthshabel commentedError 1004 "Error initializing stream/socket" seems to me like a proxy configuration issue. I thought maybe it indicated the
default/files/advagg_css
anddefault/files/advagg_css
directories weren't able to be reached (I verified the files and .gz counterpart are created). Those directories user/group belong to the webserver and the permissions are wide open.Just trying to think what else could be happening here.
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commentedWell there's a way around this now; the message can be disabled if no data is coming back. This patch has been committed (it ignores whitespace so if you want a true diff go here http://cgit.drupalcode.org/advagg/diff/?id=c98fc6c13b2cd8001db8f5af13e41...)
Comment #10
cthshabel CreditAttribution: cthshabel commentedThanks so much for the quick response.
After setting
#$conf['advagg_skip_gzip_check'] = TRUE;
, the status report shows "OK"; unfortunately the frontend is WSOD with "Failed to load resource: the server responded with a status of 500 (Internal Server Error)". If I disable (uncheck) "Enable advanced aggregation" in "admin/config/development/performance/advagg", everything comes back working on frontend. Sounds like a server configuration issue.With and without HTTPRL being used the WSOD still shows on front end. I was hoping using this patch over in HTTPRL would help me with this reverse proxy environment. Allowing me to set the port to 8083 for my backend nginx web server, but it doesn't look like it's working.
Then, I thought I could take advantage of cURL HTTP Request based on the comment made in this issue in advagg queue; however, the setup @Bandy refers to seems more like a proxy for outgoing connections to the internet. Not for incoming connections, which I believe is the issue here.
Will keep investigating. I want to get AdvAgg working!
Comment #11
cthshabel CreditAttribution: cthshabel commentedFor what it's worth, core aggregation and compression of CSS files and aggregation of JS files works fine on my current proxy environment. I'm wondering what is different with Advanced Aggregation that causes this setup to not work. Basic Advanced Aggregation module (without HTTPRL or cURL modules) breaks causing this WSOD error.
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedI put this in my settings.php file to show errors. I usually use a $_GET parameter so that I can turn it on on a per request basis.
The error level of 2 comes from this patch #1158322-199: Add backtrace to all errors
Comment #13
cthshabel CreditAttribution: cthshabel commentedAwesome. Thanks for that help to show the errors. Helps a ton!
Got this:
Fatal error: Cannot use object of type stdClass as array in advagg\advagg.module on line 1945
Looks like the WSOD was from the elseif line on 1945 where the css key was the issue. Same as this issue Fatal error: Cannot use object of type stdClass as array in advagg\advagg.module on line 1909
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedI've had like 5 bugs all related to the advagg_cleanup_settings_array() function. I'm not reproducing the bug on my end so I commit a fix and hope for the best. I've committed another fix here [#2557049-15]. BTW you can link to an issue by using this format [#NID] and you can link to a comment number in that issue by using [#NID-CNUM].
Comment #15
cthshabel CreditAttribution: cthshabel commentedAh! I have always wondered how you all link to the issues like that. Thanks for telling me.
As for this issue, AdvAgg works. I can confidently say it is working with my current configuration. I need to go start or continue the issue #2510146: Difficulties to setup this module over on HTTPRL because once I enable using HTTPRL on performance settings, things work temporarily, and then the theme breaks with lots of 404 errors. For some reason it's not making it to the backend server I don't think. I was hoping there would be a response on #2537950: Allow to define a port - and some cleanup..
I think we can close this issue now.