Missed proxy_cache with Cache-Control headr

Hello,

I’ve been playing with the proxy_cache and am having trouble determining
the intended behavior.

First, my config:

proxy_pass http://unicorn;

proxy_cache assets;
proxy_cache_key backend$request_uri;
proxy_cache_use_stale updating error timeout invalid_header;
proxy_cache_path /tmp/asset_cache levels=1:2
keys_zone=assets:10m;
proxy_temp_path /tmp/asset_tmp;

log_format cache '$time_local ’
'$upstream_cache_status ’
'Cache-Control: $upstream_http_cache_control ’
'Expires: $upstream_http_expires ’
'“$request” ($status) ’
'“$http_user_agent” ';

When receiving a generated image from the backend through this location,
here is the result when I set the Cache-Control header with a max-age:

03/Dec/2009:11:03:03 +0000 MISS Cache-Control: max-age=315576000, public
Expires: - “GET /person/avatar.png HTTP/1.1” (200) “Mozilla/5.0
(Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8
(KHTML, like Gecko) Version/4.0.4 Safari/531.21.10”

The cache always misses here, leading me to believe this item is marked
to not be cached. In the following two situations, the item is cached.
This is when Cache-control is set to just ‘public’ or s-maxage is set.
In other words, it seems like the presence of max-age stops the item
from being cached.

02/Dec/2009:11:34:18 +0000 HIT Cache-Control: public Expires: Mon, 02
Dec 2019 11:32:09 GMT “GET /person/avatar.png HTTP/1.0” (200)
“ApacheBench/2.3”
02/Dec/2009:11:35:27 +0000 HIT Cache-Control: public, s-maxage=315576000
Expires: Mon, 02 Dec 2019 11:35:23 GMT “GET /person/avatar.png HTTP/1.1”
(200) “curl/7.19.6 (i386-apple-darwin10.0.0) libcurl/7.19.6
OpenSSL/0.9.8l zlib/1.2.3 c-ares/1.6.0”

Please let me know what the intended behavior here is.

Regards,
Joshua

Posted at Nginx Forum:

One more question here.

The proxy cache doesn’t seem to return 304 Not Modified for cached items
when a matching ETag is sent to the server. Is this behavior intentional
and if so, is it planned to be added?

Joshua

Posted at Nginx Forum:

*) Bugfix: nginx did not treat a comma as separator in the
“Cache-Control” backend response header line.

Aah, I missed this in the changelog. This works great now - thanks!

Joshua

Posted at Nginx Forum:

Hello!

On Thu, Dec 03, 2009 at 06:19:16AM -0500, joshua wrote:

Hello,

I’ve been playing with the proxy_cache and am having trouble determining the intended behavior.

[…]

Please let me know what the intended behavior here is.
Looks like you are using 0.7.* and hit the bug fixed in 0.8.20:

*) Bugfix: nginx did not treat a comma as separator in the
   "Cache-Control" backend response header line.

This fix wasn’t yet merged into 0.7.* branch.

Maxim D.