Opened 2 years ago

Last modified 10 months ago

#2351 new enhancement

Support reading file ETag from additional sources

Reported by: CAFxX@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version:
Keywords: Cc:
uname -a: Linux 02dfaaf22c02 5.10.104-linuxkit #1 SMP Wed Mar 9 19:05:23 UTC 2022 x86_64 Linux
nginx -V: nginx version: nginx/1.21.6
built by gcc 10.3.1 20211027 (Alpine 10.3.1_git20211027)
built with OpenSSL 1.1.1l 24 Aug 2021 (running with OpenSSL 1.1.1n 15 Mar 2022)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-perl_modules_path=/usr/lib/perl5/vendor_perl --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-Os -fomit-frame-pointer -g' --with-ld-opt=-Wl,--as-needed,-O1,--sort-common


While the current ETag generation is perfect for most cases, there are some cases in which allowing to control the ETag value of a file would be very valuable (e.g. when the last modified time of the file is unreliable, something that is common when building container images).

To support these cases, it would be ideal to allow users to opt-in to reading the ETag value from different sources. Examples of such sources could include a specific xattr on the file being read, or a metadata file placed either in the same directory of the file being read, or in a location specified in configuration.

In this way, users could very simply generate content-based etags at container build time with something along the lines of:

find . -type f -exec xattr -s user.nginx_etag -V $(sha256sum '{}' | cut -d " " -f 1) '{}' \;

and nginx would then use it both when adding the ETag response as well as when handling conditional requests.

Change History (1)

comment:1 by Seirdy, 10 months ago

I'd also like to encourage this. The Caddy ticket tracker had a similar request, with an excellent rationale: Caddy issue 5734. It would improve reproducibility of HTTP responses across Nginx installations, and make ETags much more accurate when file contents haven't changed.

Note: See TracTickets for help on using tickets.