#271 closed defect (invalid)
'gzip_static' ignores newer 'mtime' of original file
| Reported by: | j vp | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | |
| Component: | nginx-core | Version: | 1.3.x |
| Keywords: | Cc: | ||
| uname -a: | Linux 2secure.us 2.6.18-pony6-3 #1 SMP Tue Mar 13 07:31:44 PDT 2012 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.3.9
built by gcc 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-http_geoip_module --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --with-file-aio --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-upstream-fair --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-upload-progress-module --add-module=/builddir/build/BUILD/nginx-1.3.9/mod_zip-1.1.6 --add-module=/builddir/build/BUILD/nginx-1.3.9/ngx_http_auth_pam_module-1.2 --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-upload-module-2.2 --add-module=/builddir/build/BUILD/nginx-1.3.9/nginx-rtmp-module-master |
||
Description
'gzip_static' operates on a bias towards xxx.gz files. the fact is that it ignores a newer 'mtime' of the non-gzipped file. this is for files marked 'expires epoch' and for which no caching of either type of file should be done at all. i thought it might be a problem in 'open_files', but with this off the serving problem persists.
this failure is a very serious concern in that the developer's final wishes must be expressed in the modified, non-gzipped file and not the historical gzipped one that was not updated through error or design.
Change History (6)
comment:1 by , 12 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 12 years ago
this is not readily clear from the docs:
http://wiki.nginx.org/HttpGzipStaticModule
'You should ensure that the timestamps of the compressed and uncompressed files match.'
http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html#gzip_static
'It is useful if there are no uncompressed files on the disk ...' AND
'It is recommended that the modification date and time of original and compressed files be the same.'
i am sorry, but i picked up on another site that the gzipped version would be ignored if older and your docs do not empirically state anything ... one way or another. obviously, your docs putting so much emphasis on dating similarity can easily lead to the conclusion that myself and others have drawn that the newer version will be used.
comment:3 by , 12 years ago
By itself nginx doesn't care, but if modification times do not match, it might lead to cache revalidation issues (and bandwidth wastage) in browsers/intermediate caches as Last-Modified on gzipped and non-gzipped versions won't match. Hence recommendation in docs.
comment:4 by , 12 years ago
i am not certain how the cache issues might arise since the non-gzipped file is never served.
in my last comment i was trying to suggest that the docs should reflect something like:
"if 'gzip_static" is 'on|always', the gzipped version of the file will always be served ... even if it is older than the non-gzipped file. if a gzipped file does not exist, the normal file is served."
this would surely become completely un-ambiguous to everyone.
comment:5 by , 12 years ago
You misunderstood how it works. If "gzip_static" is set to "on", non-gzipped version will be served to clients which does not support gzip. With "gzip_static always" non-gzipped version is indeed never served, but in this case it's also not expected to exist at all. This is believed to be more or less clear from docs available at http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html.
comment:6 by , 12 years ago
no, i understand how 'on' and 'always' work and i expect others do as well.
what people -- including myself, obviously -- could not fully comprehend is that there is an absolute preferrence for the gzipped version ... no matter what the dates are between it and the non-gzipped version. i can, though, see why this simplistic coding approach was chosen.
as for the docs: most people are somewhat less happy with "more or less clear" than they are with plain language that fully states the facts. this is why i previously suggested the addition of a couple of sentences of clarification in the two (2) places in the docs that i know exist. docs are all about clarity and i am certain developers with nginx are all in favor of that end.
The gzip_static doesn't check any modification times intentionally: it assumes it's user (== administrator) responsibility to provide correct gzipped version which is in sync with the original file.