1.7 - gzip_static with NGINX does NOT work without original html file

[janvitos]

Hi,

It seems using gzip_static with NGINX and Cache Enabler does NOT work without the original html file. There is a great thread about this here: https://serverfault.com/questions/571733/nginx-gzip-static-why-are-the-non-compressed-files-required/965094

It seems the try_files NGINX directive does NOT send gz files without the original html file in the same folder.

If you use gzip_static on and uncomment the compression cache key section with $ce_cache_key_compression, the client browser downloads the gz file and does NOT render the page. I have tested this using the official keycdn NGINX configuration found here: https://www.keycdn.com/support/wordpress-cache-enabler-plugin

Fortunately, I was able to make it work with a simple workaround:

• Do NOT uncomment $ce_cache_key_compression (needs to be empty)
• Make sure you add gzip_static always and gunzip on to the proper location block in your NGINX config

If you are using the keycdn NGINX configuration, your location block should start like this:

location / {
    error_page 405 = @fallback;
    recursive_error_pages on;

    gzip_static always;
    gunzip on;

That should do it. Using this method, I am able to load the pages from my website and get Cache Enabler by KeyCDN @ (https-index.html.gz) at the bottom of each page.

[janvitos]

Hi,

Any update on this?

Thank you.

[coreykn]

Thank you for sharing. The advanced configuration is commonly tweaked to fit specific requirements. It's more of a starting point right now since the plugin itself doesn't handle it directly. This means you can adjust it to fit whatever you require, even removing and/or updating environment variables. You are in complete control of your server.

The updated snippet for 1.7+ doesn't currently contain the gzip_static configuration parameter due to it requiring both the uncompressed and gzipped version to both exist. This would not work as of 1.7.1 because only what is requested is currently being generated. (Though, we will likely introduce a way to allow both of these to be generated upon a cache file being generated, so if this configuration parameter is wanted to be used it still can be. Any updates regarding this would be posted in PR #211.)

What you've provided will work. It's always forcing gzipped files to be delivered with the ability to decompress these files when a client can't (which would be highly unlikely for nearly all of your traffic).