Rack::ConditionalGet enabled in development mode / does not respect perform_caching #3583

Closed
leehambley opened this Issue Nov 9, 2011 · 9 comments

Projects

None yet

4 participants

@leehambley

This is not so much a "bug" as an oversight/mis-feature.

The Rack::ConditionalGet middleware is (mistakenly, I believe) loaded in the development environment (At least on Rails 3.1.x, and I suspect older).

This leads to unexpected behaviour when developing locally.

This can be easily fixed with:

config.middleware.delete(Rack::ConditionalGet)

Inside of the ./config/environments/development.rb file.

@koraktor
Contributor

I'm having a similar problem on Rails 3.1.3. I'm using fresh_when :etag for caching. Although in development mode disabled middleware I still get cached responses.

config.middleware.delete Rack::ConditionalGet
config.middleware.delete Rack::ETag

The web server (tried WEBrick and Thin), i.e. Rack, still send's the ETag with the response.

@leehambley

I believe the etag header should still be sent, but it shouldn't be acted upon without those middlewares.

@steveklabnik
Member

I am also not sure this is a bug, exactly. Why wouldn't you want to know if 304s are working in dev?

@leehambley

Because naturally in development mode things change too much, too often, a
304 isn't helping anyone when you're trying to write a view for the first
time, or work on a stylesheet, disabling the browser cache was my
workaround. Maybe this issue is resolveable by simply noting in the
documentation that perform_caching doesn't affect 304's.

@steveklabnik
Member

Right, I'd consider disabling the cache the right way to do it. Updating docs might be good. That said, I'm not on the core team, so we'll see what they say.

@leehambley

@steveklabnik Agree, it's rally frustrating because perform_caching doesn't actually say much about any of the kinds of caching (http, database, object, memoization, and any others I can't think of right now) - I can't say which I expect would be covered by perform_caching (at least object caching, is covered by another variable) is too generically named.

@steveklabnik
Member

Five months with no further discussion.

Since, as you say yourself, this isn't really a bug, I'm giving it a close. If you'd like to submit a PR that changes this behavior, feel free, but I personally am 👎.

@rafaelfranca
Member

I'm also 👎. For me is a good practice to test the cache logic either in development

@RafaelAlba RafaelAlba referenced this issue in n8/bust_rails_etags May 9, 2013
Open

Development Mode #1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment