Disabling 304 Not Modified responses

[jcihocki]

It would be nice if there were an option to disable 304 not modified responses in the case where you want to do post-processing of cached content (in my case, ESI in non-production environments a la Varnish in production).

As far as I can tell, the HTTP specification does not prevent returning 200 with content even if the if-modified-since or if-match freshness condition is satisfied. This allows upstream processors to work their mojo and make the final determination as to whether 304 is appropriate or not.

In the case of ESI processing, this would allow me to catch edge caching bugs before production.

Thoughts?

[rtomayko]

Yeah that makes sense to me. I'm curious, though, what other benefits would you want from rack-cache in that case? i.e., does it make sense to just remove rack-cache from the middleware pipeline entirely?

[jcihocki]

Right now removing rack-cache from the pipeline is the only option. The issue with that is your app may be returning public cache headers for content when inappropriate, but without an intermediary cache in dev/staging to surface the issue by returning the private/stale content you probably won't notice before promoting.

I considered the option of using ActionController#caches_page in dev and staging environments but 1) That's a fairly different request trajectory/code path so it's not really apples to apples 2) that mechanism is deprecated and has been removed from rails as of 4.1. and 3) It may well return 304 for fresh content as well for all I know.

The simple way to do this without touching rack-cache is to install a plugin before it in the pipeline that strips conditional get headers, but that is kind of a sledgehammer of an approach that won't work if your app needs to respond to those headers in some cases which is reasonable.