Opened 11 years ago
Closed 11 years ago
#452 closed enhancement (wontfix)
Custom ETag is not honoured by not_modified_filter module
| Reported by: | Gernot Vormayr | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | |
| Keywords: | Cc: | ||
| uname -a: | Linux nginx-test 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.4.4
built by gcc 4.7.2 (Debian 4.7.2-5) TLS SNI support enabled configure arguments: --prefix=/etc/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 --pid-path=/var/run/nginx.pid --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 --user=nginx --group=nginx --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_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --with-debug |
||
Description
This is caused by the header processing order (not_modified_filter is executed before headers_filter module):
nginx.conf:
add_header ETag 686897696a7c876b7e;
To better see this I added "http headers_filter" debug message to ngx_http_headers_filter_module.c.
debug.log:
2013/11/25 15:54:12 [debug] 28778#0: *1 http static fd: 10 2013/11/25 15:54:12 [debug] 28778#0: *1 http set discard body 2013/11/25 15:54:12 [debug] 28778#0: *1 http im:"686897696a7c876b7e" etag:"529344e6-5" 2013/11/25 15:54:12 [debug] 28778#0: *1 http headers_filter 2013/11/25 15:54:12 [debug] 28778#0: *1 HTTP/1.1 200 OK
To see what happens i changed the module ordering so headers_filter happens before not_modified_filter:
debug.log:
2013/11/25 16:07:08 [debug] 2360#0: *1 http static fd: 10 2013/11/25 16:07:08 [debug] 2360#0: *1 http set discard body 2013/11/25 16:07:08 [debug] 2360#0: *1 http headers_filter 2013/11/25 16:07:08 [debug] 2360#0: *1 http im:"686897696a7c876b7e" etag:686897696a7c876b7e 2013/11/25 16:07:08 [debug] 2360#0: *1 HTTP/1.1 304 Not Modified
Is this intended behaviour?
- If yes just close the ticket and I find another way :)
- If no - I haven't seen any bad sideeffects so far from changing this order - but I'll have another deeper, better look at it if this ordering can be changed.
Note:
See TracTickets
for help on using tickets.
The behaviour is expected.
Moving headers filter to an earlier point in header filters chain was already discussed, mostly to allow 3rd party filters to work with added headers. It's currently considered a) a bit risky and b) not enough, as various r->headers_out fields needs to be set. As of now, main purpose of headers filter is to add headers to a response sent to a client, nothing more.