Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Template caching doesn't seem to be working anymore? #1657

Closed
Bodacious opened this Issue · 10 comments

4 participants

@Bodacious

I've upgraded my rails 3.0 app to Rails 3.1 and now I seem to be seeing a lot of log activity on pages that should be completely cached and shouldn't even touch the app.

I made a basic app tonight to test this: https://github.com/Bodacious/Rails3.1caching

The root path should be cached (and is written to the public dir) but does so on every request:

Started GET "/" for 127.0.0.1 at Sat Jun 11 20:34:38 +0100 2011
  Processing by UsersController#index as HTML
Rendered users/index.html.erb within layouts/application (0.5ms)
Write page /Users/Gavin/Sites/AssetTest/public/index.html (0.6ms)
Completed 200 OK in 5ms (Views: 2.3ms | ActiveRecord: 0.3ms)
cache: [GET /assets/application-4c93ba2b40930f2b7afa684141665b62.css] fresh
cache: [GET /assets/application-177e737147b1c56843a6eb81ac8425f9.js] fresh
cache: [GET /assets/rails.png] stale, valid, store

What's up?

@neerajdotname
Collaborator

After the public/index.html page has been created by Rails, it is the job of webserver to render that file and not to forward the request to Rails. What webserver you are using?

@Bodacious
@neerajdotname
Collaborator

For me in production mode rails keep writing to public/index.html page. However in development mode it does not write the file because it loads the existing public/index.html page. I used the default webrick that comes with ruby.

I used edge rails with REE 1.8.7.

@thoefer

same behavior here as described by @neerajdotname but only with ruby 1.9.2

@thoefer

In production mode Rails (more detailed: the middleware "ActionDispatch::Static") shouldn´t be responsible in serving static assets as @neerajdotname already mentioned above. Therefore the default setting in production.rb of "config.serve_static_assets = false" let´s you skip "ActionDispatch::Static" in the middleware stack. That makes absolutely sense to me. But this implies that a dedicated webserver can serve static assets. It seems to me that webrick alone simply cannot do this. When using webrick in production mode and setting "config.serve_static_assets = true" gives you the expected behavior.

@thoefer

My conclusion: When using webrick – regardless of the mode we are running in – we always should use ActionDispatch::Static in the middleware stack. Can we agree on this or am I missing something?

@Bodacious
@thoefer

This solutions forces Rails to include ActionDispatch::Static when in production mode and running with WEBrick. What do you think? Can you verify if this is free from unwanted side effects? One (useful IMHO) side effect is that it includes the "Server" property for the view of InfoController on Rails´s default page.

@josevalim
Owner

I don't think we should hard code specifically for the webrick handler. If you want Rails to serve the static assets in production under webrick, just set the configuration option to true.

@josevalim josevalim closed this
@thoefer

Ok, was tinkering with myself about this. Do you think it´s necessary to document this in production.rb next to "(Apache or nginx will already do this)..."?

@jake3030 jake3030 referenced this issue from a commit in jake3030/rails
@fxn fxn Inline code comments for class_eval/module_eval [#1657 state:resolved]
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
a2270ef
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.