Opened 8 years ago

Closed 7 years ago

#273 closed defect (worksforme)

proxy_cache not work for 204 responses

Reported by: Cícero Verneck Corrêa Owned by:
Priority: major Milestone:
Component: nginx-core Version: 1.3.x
Keywords: cache, 204 Cc:
uname -a: Linux 10x 2.6.38-16-server #67-Ubuntu SMP Thu Sep 6 18:15:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.2.6
built by gcc 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --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-log-path=/var/log/nginx/access.log --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=/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/home/studiosol/nginx_src/ngx_cache_purge

Description

Nginx configuration for the application:

location / {
	uwsgi_pass		unix:/var/tmp/x.sock;
	uwsgi_cache		palco_cache;
	uwsgi_cache_valid	404 1m;
	uwsgi_cache_valid	302 8h;
	uwsgi_cache_valid	200 204 7d;
	uwsgi_cache_key		$uri$is_args$args;
	uwsgi_cache_lock	on;
	uwsgi_cache_use_stale	error updating timeout invalid_header http_500;
	uwsgi_cache_purge	PURGE from all;
	include			uwsgi_params;
	add_header		X-Cache $upstream_cache_status;
	uwsgi_ignore_headers	"Expires" "Cache-Control";
}

The test application has a page that returns 200 and a content whatsoever, and another that returns 204 with the contents empty.

Below lay the answer to both.

204 HEADER:

HTTP/1.1 204 NO CONTENT
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 04 Jan 2013 21:19:51 GMT
Server: nginx
X-Cache: MISS

200 HEADER:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Fri, 04 Jan 2013 21:37:00 GMT
Server: nginx
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Cache: HIT

No matter the number of requests, a request that returns 204 is never cached.

Change History (2)

comment:1 by Maxim Dounin, 8 years ago

Works fine here (though I tested it with proxy as in ticket summary, not uwsgi as in your config):

$ env TEST_NGINX_VERBOSE=1 prove -v proxy_cache.t
proxy_cache.t .. 
1..12
# >> GET /204 HTTP/1.0\x0a
# >> Host: localhost\x0a
# >> \x0a
# << HTTP/1.1 204 No Content\x0d\x0a
# << Server: nginx/1.3.10\x0d\x0a
# << Date: Sat, 05 Jan 2013 13:27:43 GMT\x0d\x0a
# << Connection: close\x0d\x0a
# << X-Cache-Status: MISS\x0d\x0a
# << \x0d\x0a
ok 1 - proxy request 204
# >> GET /204 HTTP/1.0\x0a
# >> Host: localhost\x0a
# >> \x0a
# << HTTP/1.1 204 No Content\x0d\x0a
# << Server: nginx/1.3.10\x0d\x0a
# << Date: Sat, 05 Jan 2013 13:27:43 GMT\x0d\x0a
# << Connection: close\x0d\x0a
# << X-Cache-Status: HIT\x0d\x0a
# << \x0d\x0a
ok 2 - proxy request 204 cached
...

With the following patch for the test suite:

--- a/proxy_cache.t
+++ b/proxy_cache.t
@@ -59,6 +59,8 @@ http {
 
             proxy_cache_use_stale  error timeout invalid_header http_500
                                    http_404;
+
+            add_header X-Cache-Status $upstream_cache_status;
         }
 
         location /fake/ {
@@ -72,6 +74,10 @@ http {
 
         location / {
         }
+
+        location = /204 {
+            return 204;
+        }
     }
 }
 
@@ -85,6 +91,9 @@ EOF
 
 ###############################################################################
 
+like(http_get('/204'), qr/MISS/, 'proxy request 204');
+like(http_get('/204'), qr/HIT/, 'proxy request 204 cached');
+
 like(http_get('/t.html'), qr/SEE-THIS/, 'proxy request');
 
 $t->write_file('t.html', 'NOOP');

You may want make sure you are able to reproduce the problem without 3rd party modules/patches, and provide debug log with two requests to 204 to see what goes wrong in your case (see http://nginx.org/en/docs/debugging_log.html).

comment:2 by Maxim Dounin, 7 years ago

Resolution: worksforme
Status: newclosed

Feedback timeout.

Note: See TracTickets for help on using tickets.