Jason,

Instead of setting the :default_ttl option, which obviously 
indiscriminately sets an undesirable Cache-Control header, set the 
default timeout on SiteController like so:

config.after_initialize do
    SiteController.cache_timeout = 1.year
end

In general, I've found that when a page is not to be cached, your 
application should return "private, no-cache, max-age=0" (and/or 
optionally "must-revalidate") in the Cache-Control header.  If you have 
any max-age or s-max-age option with something other than 0 in there, it 
will consider it cacheable.  Most important, however, is "private", 
which indicates that the response is specific to the requestor and 
should not be cached.  Details here:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

If you need responses from your extension controllers cached, make sure 
to use the "expires" method in your controller.  Radiant::Cache will 
handle the result appropriately.

Sean

Jason Fox wrote:
> I'm having an issue in production that I can only sometimes reproduce 
> locally.  The issue involves Rack-Cache, Redirects and the ssl_requirement 
> plugin running within the latest Radiant CMS.  Let me lay it out for you...
>
> Radiant is using Rack-Cache to do it's caching these days as we all know.  
> Here's how I have it configured:
>
> config.middleware.use ::Radiant::Cache, 
>   :cache_key => 
>     Proc.new { |request| 
>         "http://#{request.env["HTTP_X_FORWARDED_HOST";] || 
> request.host}#{request.path}".downcase 
>     }, 
>   :entitystore => "memcached://#{CACHE_SERVER}:11211", 
>   :metastore => "memcached://#{CACHE_SERVER}:11211", 
>   :verbose => true, 
>   :default_ttl => 31536000 # one year
>
> You'll note that I'm using a custom cache_key function here.  There's good 
> reason for it, but, I won't bore you with that now.  Also notice that I've 
> hardcoded "http" in the cache_key (bad idea - more on that later).  The 
> second thing that you might notice is that I'm telling Rack-Cache to 
> basically NEVER expire my cached pages.  There's also a good reason for that, 
> but, I won't go into it.  Continuing on...
>
> There is a page in my application /signup/form that is rendered by a custom 
> Radiant extension that we've written.  That extension's controller which 
> handles the signup/form request specifies that the form action should require 
> ssl like so:
>
> ssl_required :form 
>
> What I've observed in production (sometimes) and locally (sometimes) is that 
> Rack-Cache is caching the 302 redirect from http://HOSTNAME/signup/form (a 
> dynamic request) to https://HOSTNAME/signup/form.  Locally it's cached in the 
> other direction because the ssl_requirement plugin won't enforce SSL if the 
> request is deemed to be "local," i.e., local_request? returns true.  The 
> effect of this is an infinite redirect.  How come?  Well, recall the bad idea 
> of hardcoding the "http" in the cache_key function above?  Essentially what 
> it seems is happening is this:
>
> 1) Browser requests http://HOSTNAME/signup/form
> 2) ssl_requirement plugin redirects user to https://HOSTNAME/signup/form
> 3) Rack-Cache caches the 302 response headers in the meta under the key: 
> http://HOSTNAME/signup/form
> 4) Browser requests http://HOSTNAME/signup/form
> 5) Rack-Cache checks the cache using the key: http://HOSTNAME/signup/form and 
> finds a fresh response (cached in #3 above)
> 6) Rack-Cache responds with the 302 again; go back to step #1; infinite loop 
> ensues
>
> So fine, I made a mistake.  I should not have hardcoded the protocol in my 
> custom cache_key, fine.  Mystery solved, right?  Wrong. 
>
> What still puzzles me is why Rack-Cache is caching the 302 response for a 
> dynamic page.  Furthermore why is it only caching it some-of-the-time and not 
> all-of-the-time.  It seems that there is some sequence of requests after a 
> memcached restart (that clears the cached 302 and everything works again) 
> that causes it to cache the response.  The one time I was able to reproduce 
> it locally I captured the meta it had cached from memcached.  Here's what I 
> found:
>
> [[{"SERVER_NAME"=>"127.0.0.1",
>  
> "HTTP_ACCEPT"=>"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
>  "HTTP_HOST"=>"127.0.0.1",
>  "HTTP_X_FORWARDED_HOST"=>"127.0.0.1",
>  "HTTP_USER_AGENT"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; 
> rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5",
>  "REQUEST_PATH"=>"/signup/form",
>  "SERVER_PROTOCOL"=>"HTTP/1.1",
>  "HTTP_ACCEPT_LANGUAGE"=>"en-us,en;q=0.5",
>  "REMOTE_ADDR"=>"127.0.0.1",
>  "PATH_INFO"=>"/signup/form",
>  "SERVER_SOFTWARE"=>"Mongrel 1.1.5",
>  "SCRIPT_NAME"=>"",
>  "HTTP_VERSION"=>"HTTP/1.1",
>  "HTTP_X_FORWARDED_SERVER"=>"127.0.0.1",
>  "HTTP_X_FORWARDED_PROTO"=>"https",
>  "REQUEST_URI"=>"/signup/form",
>  "SERVER_PORT"=>"80",
>  "HTTP_X_FORWARDED_FOR"=>"127.0.0.1",
>  "HTTP_ACCEPT_CHARSET"=>"ISO-8859-1,utf-8;q=0.7,*;q=0.7",
>  "REQUEST_METHOD"=>"GET",
>  "QUERY_STRING"=>"",
>  "GATEWAY_INTERFACE"=>"CGI/1.2",
>  "HTTP_CONNECTION"=>"Keep-Alive",
>  "HTTP_ACCEPT_ENCODING"=>"gzip,deflate"}, 
> {"Location"=>"http://127.0.0.1/signup/form";,
>  "X-Content-Digest"=>"531b3a921cf45cc6ed54e6da8f19b0c12dd4900e",
>  "Date"=>"Wed, 18 Nov 2009 18:38:28 GMT",
>  "Content-Type"=>"text/html; charset=utf-8",
>  "X-Runtime"=>"11",
>  "Content-Length"=>"96",
>  "Set-Cookie"=>"",
>  "Cache-Control"=>"no-cache, s-maxage=31536000",
>  "X-Status"=>"302"}]]
>
> This particular request was local so the redirection was going in the 
> opposite order, i.e., https => http. Notice that the Cache-Control is set to 
> "no-cache."  It's my understanding that "no-cache" means that the response 
> should not be cached no matter what.  However, also notice that the s-maxage 
> (which was recently introduced in Rack-Cache) is set to 1 year (from my 
> configuration of Rack-Cache above).  Now, perhaps s-maxage takes precedence 
> over no-cache, but even if that was the case, why does it only cache the 
> request's response only some of the time?
>
> Any help or insight into this problem would be much appreciated.
>
> Thanks in advance,
> Jason Fox
> jfo...@gmail.com
>
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>
>   

_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to