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
> [email protected]
>
> _______________________________________________
> Radiant mailing list
> Post: [email protected]
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>
>
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
