CODEWITHSUNDEEP
ruby-on-railsnginx
idoimaging
idoimaging

Reputation: 784

Nginx Rails/Passenger is not serving gzipped asset files

Nginx 1.10.1 Rails 5.0.1. The asset pipeline is making both the zipped and native versions of the css and js files, but only the uncompressed is served to the browser. I can see both versions in public/assets and I can use curl to retrieve the zipped version by appending '.gz' to the css/js asset url delivered to me.

I am using a CDN (AWS CloudFront) but have tested without the CDN and anyway it should still point me to the zipped version, right?

nginx has --with-http_gzip_static_module. Using this answer as a guide, my nginx config (edited) has:

http {
    server {
        listen       80;
        server_name  idoimaging.com www.idoimaging.com;
        return 301 https://$server_name$request_uri;
    }

    server {
        listen 443 ssl;
        server_name  idoimaging.com www.idoimaging.com;
        root /var/www/idoimaging/current/public;
        location ~ ^/(assets)/ {
            gzip_static on;
        }
    }
}

I've also tried /assets/ as the regex in location. In my production.rb:

# Have also tried setting this to false
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?
config.middleware.insert_before(Rack::Sendfile, Rack::Deflater)
config.assets.compress = true
config.assets.js_compressor = Uglifier.new(mangle: false)

I'm testing with Chrome with cache disabled, also for speed with curl https://idoimaging.com | grep assets which I believe should have the same behaviour as the browser?

I don't know why nginx will not serve the gzip'ed js/css asset files when they are present.

EDIT: I've also seen this guide that takes another approach: Use Rails as the static asset server instead of nginx. Would this be a better approach?

Upvotes: 0

Views: 923

Answers (1)

Rich Seviora
Rich Seviora

Reputation: 1809

Given that Rails is producing the gzipped assets, we can be confident that the issue resides solely with nginx. So let's focus there!

I believe Nginx is faster at serving static assets than Rails is, so I'd stay away from using it as a static asset server in any event.

Now looking at the URL you provided (https://idoimaging.com), your server appears to be providing gzipped files. So the issue is just with your testing approach (assuming this is the correct URL, and you have not changed the server configuration since this post).

Your curl command doesn't include the Accept-Encoding: gzip header, which tells the server your client is capable of handling gzipped files. Without it, Nginx will serve the uncompressed versions. You can see the difference in commands and outputs in this gist. The difference is in the Content-Length and Content-Encoding response headers.

If you're seeing something different, let me know!

Edit 1

That's odd, CloudFront appears to have cached redirects for both your CSS and your JS.

richardseviora:Richards-MacBook-Pro@~> curl "https://cdn.idoimaging.com/assets/application-0cd41e63d35c1e5a7ab76ded23fbaf2ef1d1b786144134a80a1dfa9c765cff0d.css" -I -H "accept-encoding: gzip"
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Server: nginx/1.10.1
Date: Thu, 23 Feb 2017 03:30:49 GMT
Location: https://idoimaging.com/assets/application-0cd41e63d35c1e5a7ab76ded23fbaf2ef1d1b786144134a80a1dfa9c765cff0d.css
Age: 942
X-Cache: Hit from cloudfront
Via: 1.1 d8b73f8fefd106d5c95f11977e132c46.cloudfront.net (CloudFront)
X-Amz-Cf-Id: ao8PwibmSj1JhmfbmuNfC2gYi9x-RTcCrJDAqLWAUIyOjP_3qYTGQA==


# It should look like this instead.
richardseviora:Richards-MacBook-Pro@~> curl -I -H "accept-encoding: gzip" "http://cdn.sweatrecord.com/assets/application-b932da0ddcf53d3650da5135b083224e863b349c784f3d1e3ca992b36ce3e31d.css"
HTTP/1.1 200 OK
Content-Type: text/css
Connection: keep-alive
Accept-Ranges: bytes
Content-Encoding: gzip
Date: Thu, 23 Feb 2017 03:50:13 GMT
Last-Modified: Mon, 30 Jan 2017 16:29:44 GMT
Server: Apache
Vary: Accept-Encoding,Origin
X-Cache: Miss from cloudfront
Via: 1.1 8b5947aba7280333032d4dcdd80b3489.cloudfront.net (CloudFront)
X-Amz-Cf-Id: FN9FyKl0RCpNTTqBwb0WyQhbDd-rEyyQ05eCtaFCD8YaH_FtjG7Q8Q==

This is Nginx issue, but I'm not sure where exactly because CloudFront will cache 301s.

Upvotes: 1

Related Questions