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:

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.
)
?>
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cthshabel created an issue. See original summary.

cthshabel’s picture

Issue summary: View changes
mikeytown2’s picture

-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.

mikeytown2’s picture

Provide a link to http://checkgzipcompression.com/?url= where the url has been filled in.

cthshabel’s picture

http://checkgzipcompression.com/?url=https%3A%2F%2Fwww.veuit.com

I checked this before too and the results were were 80% gzipped

cthshabel’s picture

FYI... 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 errors

cthshabel’s picture

Error 1004 "Error initializing stream/socket" seems to me like a proxy configuration issue. I thought maybe it indicated the default/files/advagg_css and default/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.

  • mikeytown2 committed c98fc6c on 7.x-2.x
    Issue #2568381 by mikeytown2: Provide a way to test gzip via 3rd party...
mikeytown2’s picture

Status: Active » Fixed
FileSize
2.84 KB

Well 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...)

cthshabel’s picture

Thanks 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!

cthshabel’s picture

For 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.

mikeytown2’s picture

I 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.

  // Show Errors in output
  ini_set('display_errors', '1');
  // Report all php errors.
  error_reporting(-1);
  // Display errors using drupal_set_message().
  $conf['error_level'] = 2;

The error level of 2 comes from this patch #1158322-199: Add backtrace to all errors

cthshabel’s picture

Awesome. 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

mikeytown2’s picture

I'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].

cthshabel’s picture

Ah! 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.

Status: Fixed » Closed (fixed)

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