nginx-proxy
nginx-proxy copied to clipboard
gzip_types has no effect without setting gzip and gzip_proxied
I was just reading the NGINX documentation for the various directives in the nginx-proxy template because NGINX is all new to me (I've switched to nginx-proxy from a handcrafted Apache configuration).
I noted that gzip is off by default (http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip). I checked the global NGINX configuration included in the Docker nginx image* and found that there are no overrides there so it really is off. I also confirmed empirically** that gzip is not being enabled using curl.
I would open a PR that adds gzip on
above gzip_types
, but I note that gzip_proxied
must also be set to something other than its default of off for gzip to actually be enabled; there are several options (http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_proxied) and it's not clear to me what would be most appropriate for nginx-proxy's template.
Assuming I've not missed something, perhaps this issue can be used to discuss and agree on a sensible value for gzip_proxied
, and then a PR can be made?
130 david@maple:~/Deploy/proxy/docker-gen⟫ sudo docker run -it --rm nginx:1 bash
root@7e1d979519b4:/# cd /etc/nginx/
root@7e1d979519b4:/etc/nginx# ls
conf.d fastcgi_params koi-utf koi-win mime.types nginx.conf scgi_params uwsgi_params win-utf
root@7e1d979519b4:/etc/nginx# cat nginx.conf | grep gzip
#gzip on;
**
david@ash:~$ curl -I -H "Accept-Encoding: gzip,deflate" https://www.dhpiggott.net
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 04 Apr 2015 09:56:48 GMT
Content-Type: text/html
Content-Length: 3730
Connection: keep-alive
Last-Modified: Fri, 03 Apr 2015 22:46:34 GMT
ETag: "551f184a-e92"
Accept-Ranges: bytes
Strict-Transport-Security: max-age=15768000
compare to the result when I add gzip on
and gzip_proxied any
to my template:
david@ash:~$ curl -I -H "Accept-Encoding: gzip,deflate" https://www.dhpiggott.net
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 04 Apr 2015 09:59:20 GMT
Content-Type: text/html
Connection: keep-alive
Last-Modified: Fri, 03 Apr 2015 22:46:34 GMT
ETag: W/"551f184a-e92"
Strict-Transport-Security: max-age=15768000
Content-Encoding: gzip
I found https://github.com/h5bp/server-configs-nginx/blob/master/nginx.conf which looks like it's had quite a few eyes on it and so suggests that gzip_proxied any
is reasonable. The other gzip directives in it might also be worth copying.
I actually brought up the issue about whether or not gzip_types
was having any effect here: https://github.com/jwilder/nginx-proxy/pull/81#issuecomment-69669974
It might be easier if you could provide a PR/diff for people to test, since I don't actually see you testing your change against jwilder/nginx-proxy
.
Ah, right, I hadn't seen that, sorry!
Having read it now I'm struggling to figure out what you mean by
I just realized that gzip_proxied controls whether proxied requests get gzipped, not proxied responses.
And I'm also not sure what you mean by
I don't actually see you testing your change against
jwilder/nginx-proxy
Do you just mean that my examples above didn't include any references to an nginx-proxy image? That's true; I'm maintaining a private Git repo for ease of deployment that includes my TLS certs and a pair of deployment scripts that startup separate docker-gen
and nginx
instances.
I initialised the repo with the nginx.tmpl from this repo and then made a few changes of my own (some which I've presumed would not be wanted here upstream and one or two that may be).
For the purposes of this issue though my deployment can be considered equivalent to nginx-proxy; the change I've applied to my nginx.tmpl is to add this after the # HTTP 1.1 support
block:
# Compression
# Taken from https://github.com/h5bp/server-configs-nginx/blob/master/nginx.conf
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rdf+xml application/rss+xml application/schema+json application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-javascript application/x-web-app-manifest+json application/xhtml+xml application/xml font/eot font/opentype image/bmp image/svg+xml image/vnd.microsoft.icon image/x-icon text/cache-manifest text/css text/javascript text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy text/xml;
My comment about it gzipping proxied requests as opposed to responses was wrong. That's what I meant about me being confused :confused:
Here's an explanation of what gzip_proxied
actually does from the Nginx docs:
By default, NGINX does not compress responses to proxied requests (requests that come from the proxy server). The fact that a request comes from a proxy server is determined by the presence of the Via header field in the request. To configure compression of these responses, use the gzip_proxied directive. The directive can have a number of parameters specifying which kinds of proxied requests NGINX should compress. For example, it is reasonable to compress responses only to requests that will not be cached on the proxy server. For this purpose the gzip_proxied directive has parameters that check the
Cache-Control
header field in a response and compresses the response if the field has the no-store, no-cache, or private values. In addition, it must also include the parameter that checks the value of theExpires
header field.
In the case of jwilder/nginx-proxy
, I don't think it should be doing any gzipping by default, which it currently isn't doing because it doesn't have gzip on
. Because of that, I think that the current gzip_types
should be removed from nginx.tmpl
since they are misleading and not doing anything.
If a user wants their instance of jwilder/nginx-proxy
to gzip everything by default, they can add a custom configuration file to enable gzip on
themselves with whatever setting they want for gzip_proxied
, as described here: https://github.com/jwilder/nginx-proxy#custom-nginx-configuration
One thought I did have after reading those docs is that it probably makes sense to have jwilder/nginx-proxy
set a Via
header, which it currently doesn't do.
Thanks for the explanation. I don't really have an opinion one way or the other as to whether jwilder/nginx-proxy
should do gzipping by default, so again just a question out of curiosity: why is it that you think it shouldn't?
I think the settings in nginx-proxy
should be as backend-agnostic as possible, which to me includes not making assumptions about whether or not payloads should be gzipped in the default configuration.
Got it, thanks. I guess this issue can be closed now then, unless it should be left open to track removing gzip_types
from nginx.tmpl
?
I'd say leave it open and let @jwilder make the call about whether to close it. Who knows, he may even want to have gzip on
by default for all I know.
I had intended for it to be on and working originally. Keep this open since it seems to be a bug. If people feel it should not be on by default then we can open a separate issue to discuss removing it.
I had originally intended the image to be secure and performant by default so you wouldn't need to muck with nginx details. The image didn't have all the extension points (nor users) that it has now so maybe it's worth revisiting that choice now.
Any update on this? These are some basic settings I found recommended for enabling gzip which I'm using right now:
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
# This is already in the template:
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
Looks like gzip is still off in jwilder/nginx-proxy:latest
. Any update on getting this merged in?
#gzip on;
Google PageSpeed Insights says I should enable compression but checkgzipcompression.com reports that it is enabled. But I can't find gzip on;
in the tmpl file. So this is still an issue?
/Edit: a my_proxy file with
gzip on;
gzip_proxied any;
gzip_vary on;
seems to fix most problems
hello. i hade a simmalr issue. but not undestanding why the gziping doesnt occure when ussing reverse proxy frontend
https://redmine.lighttpd.net/issues/2844
My nginx backend server conf:
##
# `gzip` Settings
#
#
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;
Could'nt this be closed? There are many things mixed up here that lead to no result. This proxy does not enable gzip because this is an app decision and shouldnt be a default setting in the proxy itself. It also defines proxy_http_version 1.1. This should allow for gzip passthrough, so whatever HTTP endpoint you serve towards this project, as long as that one delivers gzipped content, it should be passed through to the client.
Just tested it myself, because of some gzip_static nightmare I had some weeks ago with another project: I can enable gzip_static on my app, place a test.js and test.js.gz file and service it through this proxy without problems. If the gz file is present it will be served gzipped, if only the test.js file is present, nothing gets gzipped. Same goes with a simple test on the app(!), this will get passed through the proxy as well:
gzip on;
gzip_proxied any;
gzip_types "*";
In this scenario gzip_proxied must be set/allowed on your app(!). So its up to your app if you want to use gzip, the proxy just does its job to pass it through.
Could'nt this be closed? There are many things mixed up here that lead to no result. This proxy does not enable gzip because this is an app decision and shouldnt be a default setting in the proxy itself. It also defines proxy_http_version 1.1. This should allow for gzip passthrough, so whatever HTTP endpoint you serve towards this project, as long as that one delivers gzipped content, it should be passed through to the client.
Just tested it myself, because of some gzip_static nightmare I had some weeks ago with another project: I can enable gzip_static on my app, place a test.js and test.js.gz file and service it through this proxy without problems. If the gz file is present it will be served gzipped, if only the test.js file is present, nothing gets gzipped. Same goes with a simple test on the app(!), this will get passed through the proxy as well:
gzip on; gzip_proxied any; gzip_types "*";
In this scenario gzip_proxied must be set/allowed on your app(!). So its up to your app if you want to use gzip, the proxy just does its job to pass it through.
Why would one want it done on the app level? Isn't that less performant? Didn't @jwilder want it on by default? Do these need to be added per-VHOST now? Or in the mounted nginx_conf/_data/default.conf - which is already full of generated config?
I also tested the documentation for proxy-wide settings: https://github.com/jwilder/nginx-proxy#proxy-wide It does not seem to work for the gzip settings. How did you enable gzip on your own servers @jwilder?
@dm17 it works fine, just tested it myself. The mentioned/linked h5bp gzip config works well.
Place that compression.conf
file into the conf.d
directory as the proxy-wide instructions you linked tell you to do. Then anything nginx-proxy handles will gzip based on those settings. Make sure you restart the nginx-proxy container afterwards if already running(or shell into the container and reload the config).
@dm17 it works fine, just tested it myself. The mentioned/linked h5bp gzip config works well.
Place that
compression.conf
file into theconf.d
directory as the proxy-wide instructions you linked tell you to do. Then anything nginx-proxy handles will gzip based on those settings. Make sure you restart the nginx-proxy container afterwards if already running(or shell into the container and reload the config).
Thanks! That works! I had everything in my compression.conf except "gzip on;" because I didn't realize I could actually enable it that way. I was confused.
I had originally intended the image to be secure and performant by default so you wouldn't need to muck with nginx details.
I felt the same way, and now having to muck with the nginx configs for the first time I felt like maybe I was doing something "wrong."
What are your thoughts on having a quick yaml config option to enable gzip compression? Either as a boolean or an array to enable it per vhost.
At the very least we should probably add instructions to the README mentioning gzip explicitly, maybe as an example, in the proxy-wide settings section. I know I searched through the README for "gzip" and "compression" and nothing came up, I was surprised.
I'm adding that referenced compression.conf to my conf.d. But for some reason, I'm getting a flood of "invalid value" messages on build of the container. There isn't a lot of description around why. Any ideas?
@buswedg That message can be ignored. See: https://github.com/nginx-proxy/docker-gen/pull/494
Ah this thread was amazing. Thank you for the help.