Opened 11 years ago
Closed 11 years ago
#260 closed enhancement (wontfix)
extend `gzip_static` to accept more extensions than just `.gz`
| Reported by: | Christian Bönning | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-module | Version: | 1.3.x |
| Keywords: | Cc: | ||
| uname -a: | |||
| nginx -V: |
nginx version: nginx/1.3.9 (+spdy 54)
built by gcc 4.3.2 (Debian 4.3.2-1.1) TLS SNI support enabled configure arguments: --prefix=/opt/nginx --user=www-data --group=www-data --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-file-aio --with-http_flv_module --with-http_mp4_module --with-http_dav_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_image_filter_module --with-http_sub_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_xslt_module --with-http_secure_link_module --with-ipv6 --with-pcre-jit --without-http_ssi_module --without-http_memcached_module --with-openssl=/usr/src/nginx/source/openssl-1.0.1c --with-pcre=/usr/src/nginx/source/pcre-8.31 --with-zlib=/usr/src/nginx/source/zlib-1.2.7 --with-sha1=/usr/src/nginx/source/openssl-1.0.1c --with-md5=/usr/src/nginx/source/openssl-1.0.1c --add-module=/usr/src/nginx/modules/git/nginx-cache-purge/ --add-module=/usr/src/nginx/modules/git/nginx-headers-more/ |
||
Description
I'm using nginx in combination with TYPO3 CMS and would like to take advantage from gzip_static. TYPO3 does provide a way to pre-compress a couple of ressources.
However those ressources are written as - for example - file.css.gzip which isn't recognized by nginx's gzip_static module due to the fact that the module does look only for files having extensions like .gz.
Is there any chance to extend the gzip_static configuration directive to accept - besides its current options - as a second parameter a list of extensions? I could imagine something like gzip_static on "gz gzip gzip.css gzip.js"
Change History (4)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Everybody who asking for such feature (list of extensions) should know that each additional extension will result in additional syscall (file system lookup) per request.
In other words, are you guys sure that you are willing to sacrifice performance, instead of doing simple change in your scripts?
follow-up: 4 comment:3 by , 11 years ago
please note my last para from my last comment. i do not see any merit in the original request. i am certain that almost everyone can live with .css.gz', .js.gz', et cetera. moreover, i cannot imagine anyone wanting to have the gzip indicator moved from being the last extent of the file name.
my comment riding on this "enhancement" request is that '.svgz' should be added to the current '.gz' processing. this is a simple "OR" (.gz|.svgz) in the file system call. the mime type of '.svgz' is already supposed to be "svg+xml", so this is not really a change.
what this would do would bring nginx into standards compliance as to the file handling of '.svgz' files and all within the current 'gzip_static' code (with only minor mods).
comment:4 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Replying to j vp <j.vonpreussen@gmail.com>:
my comment riding on this "enhancement" request is that '.svgz' should be added to the current '.gz' processing. this is a simple "OR" (.gz|.svgz) in the file system call. the mime type of '.svgz' is already supposed to be "svg+xml", so this is not really a change.
There is no such thing as "OR" in the open() system call.
There are no plans to extend gzip_static with additional extensions, closing this as "wontfix".
one thing fast-growing in usage is '.svg' and the dramatic band-width reduction accomplished by gzipping into '.svgz'. webmasters conscious of CPU utilization will most certainly want to pre-compress as much as possible. it is not standards compliant to serve files as '.svg.gz', but, for now, this is the only way to use the 'gzip_static' facility. since '.svgz' has long been an accepted mime-type for gzipped svg+xml, it seems quite timely for nginx to begin handling it properly.
otherwise, one must code a special 'location' for only '.svgz' and add the 'type' and 'encoding' headers that would be missing.
i must admit, that this original request does not seem to make much sense considering the standard practice currently extant. not having the gzip-indicating extent somewhere other than the last one does not enhance either processing or human recognition.