missed proxy_cache with Cache-Control headr

joshua nginx-forum at nginx.us
Thu Dec 3 14:19:16 MSK 2009


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: http://forum.nginx.org/read.php?2,27665,27665#msg-27665





More information about the nginx mailing list