gzip_static module does not obey mime types
Richard Stanway
r1ch+nginx at teamliquid.net
Fri Aug 24 15:11:27 UTC 2018
This seems intentional, per the documentation at
http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html:
"The following directives are also taken into account: gzip_http_version,
gzip_proxied, gzip_disable, and gzip_vary."
No mention of gzip_types. I recommend only enabling gzip_static in a
location block where you know you have pre-compressed assets present.
On Fri, Aug 24, 2018 at 12:55 PM Matt Gadient <jdi_knght at hotmail.com> wrote:
> I've noticed for a while that when gzip_static is enabled it checks
> *every* file it serves for a .gz extension, not just the ones listed in the
> gzip_types. For example in a page with 1 html and 30 images you'll have 61
> requests to the file system: 1 for the correct .html.gz file, 30 for the
> non-existent .png.gz files, and 30 for the .png files.
>
> You can verify this on a running server that has gzip_static on, with
> "strace -p PID 2>&1 | grep gz" (where PID is an nginx worker's PID). Visit
> a page of the site that has images and you'll get a whole bunch of "-1
> ENOENT (No such file or directory)" in the output attached to
> /var/www/website/image.png.gz files.
>
> I am wondering if this is intentional or if it is a bug. Thanks for your
> time.
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180824/dec10bfe/attachment.html>
More information about the nginx
mailing list