Time-based output caching is writing cache when it is set to "never cache"

For it does not make sense to cache not the result, but cache the output. The output will not change, but the database would have to work.

Nonetheless: You are right, the cache is stored, but the cache is as far as i see, never loaded. Here is a small patch, which checks, on set, whether it should get stored.

dereine is right. Why would you cache the output but not the query? You'll run the query and throw away the result, which is less performant.

I find this issue confusing.

Setting needs work based on my comments in #3.

Atleast this saves space in the cache table, thats ok to fix, i think

Just a quick note on this: for one of our production sites, this bug was causing some big problems. We are actually using the reverse of what bloto has described - the queries are cached (1 hour) but the HTML is not cached. Applying the patch in #1 along with the extra code in #2 appears to have fixed the issue.

No updates to issue/patch in 3 months

This is really nasty.

I'm running 6.x-2.12. Views get cache options seem to be ignored.
I have a view, that should never be cached, because I send a 404 status header in the Empty text.

I've tried setting cache options to "None" and "Time base" rendered output to "Never". But I only get a 404, the first time I GET the view. All following GET's will 200 OK.

For some reason, responses to HEAD requests do have the desired status codes.

#8: Your issue has nothing to do with this closed issue. You shouldn't attempt to hijack issues.

That said, you seem to be assuming Views is responsible for the caching without actually confirming that, and are blaming Views. There are many layers of caching, and Views is very good about only caching when told to. I am 100% certain that Views does not cache when not configured to; almost nothing would ever really work if it cached unexpectedly.

tl;dr
Setting "cache mode" to "disabled" helped. I ended up working around it, by installing http://drupal.org/project/cacheexclude and setting an exception for the view page url. Any pointers to the real issue are welcome; so far it's 100% certainly not Views cache. And 100% certainly not something outside of Drupal :-)

I'm not trying to hijack issues [sic]. This issue seemed to address the same symptoms that were hurting me.

I'm not caching at the client (python-requests lib, urllib2, curl)
I'm not using a proxy.
I'm not caching in front of the webserver with a reverse proxy (Drupal 6 headers really make that pointless).
So it must be somewhere in Drupal.
The Drupal Performance "cache mode" is set to "normal" which has "no side effects", and setting the caching on the view to a non zero temporal, seemed to help. So I suspected Views, though the temporal setting could be a coinciding separate timings.

The different behaviour on HEAD and GET responses made it quite a chore to debug. Which is my stupid fault, I shouldn't have assumed the same headers and check the basic correctness of the view with HEAD requests (even though I was just interested in the headers), because the application was using GET. I was assuming since my Status was set in the body logic, and that was clearly executed for every HEAD, then *surely* it should be executed for the GET to. Not the case.

I basicly need something similar to #1295824: Add possibility to hide view or 404 if no results, perhaps among "No Results Behavior", but I don't wan't to "lead to a 404 page", just set the HTTP Status code to 404, if there is no node that conforms to the set filters. I do it now with a PHP code "empty text"

header('HTTP/1.1 404 Not Found');

Edit:
Using

drupal_set_header('HTTP/1.1 404 Not Found');

fixes the cache inconsistencies. It makes the response get cached with the right status header. Good enough.

This is a fresh patch, containing code from #1 and #2, against 3.6+dev

As merlinofchaos points out in #3 out: "Why would you cache the output but not the query"
That user error can be addressed in the settings UI.

IMO the following 2 issues are complementary:
#1930324: Time-based caching does not work properly when it is set to 'Never cache'
#652610: Time-based output caching is writing cache when it is set to "never cache"

The following may be a duplicate:
#1503026: Views and time based caching

better title.

Removed extra whitespace.

I have the feeling that "0" could stand for infinity, so we might check for >= 0 ?

Not a bad idea.

#14 + 15 works for me.

#17 works for me.

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

This is a re-upload of #17.

Thanks!

I just tested this on Drupal 9.4.x, standard install, and found that caching is working correctly, with the caveat that this is the first time I have looked closely at views caching and the tables. I used the a duplicate of the content view and played around with the various settings and could not create a situation where the caching or lack of it was not working as expected.

I think the thing to do here is move it back to Drupal 7 and restore the fixed status.