Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
We had an issue where an error happened on the page, and then anonymous users got the cached error page, from the internal page cache.
Proposed resolution
Prevent caching of responses generated in DefaultExceptionSubscriber.
They set status code 500, but it looks like we cache those anyway.
Should we exclude 5xx from the page cache in general?
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#17 | never-cache-server-errrors-2429671-17-interdiff.txt | 1.75 KB | Berdir |
#17 | never-cache-server-errrors-2429671-17.patch | 3.12 KB | Berdir |
Comments
Comment #1
Wim LeersComment #2
dawehnerwow
Comment #3
BerdirFix and test.
Now I feel OK with setting it to major, because I think it is...
$response->isServerError()++
Comment #4
BerdirComment #6
Wim LeersLooks great :)
Comment #7
alexpottNot entirely sure about this change. Amazon caches 500s see http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HTTPSt...
At the very least this should be configurable or maybe inside the response policy so the behaviour can be swapped out.
Comment #8
Wim LeersExcellent remark & suggestion. Implemented that.
Comment #9
BerdirI'm not sure if that is really necessary, this is a regression from 7.x, making it configurable is not :)
We discussed that this could also be a private service, but you prefer to a have a default response policy class, fine either way.
Now we need to someone to RTBC this again ;)
Comment #10
Wim LeersActually, private service is totally fine by me too. I think I said that in IRC too? Either way works for me.
The sole reason I went for this: symmetry between these two:
By introducing
DefaultResponsePolicy
, it's fully symmetrical.But no strong opinion.
Comment #11
znerol CreditAttribution: znerol commentedIn my point of view D7 is wrong in this particular case, there is no reason to not cache error responses. We should probably cache them with a low ttl though.
Comment #12
BerdirIMHO, that's tricky, because errors like this often happen only once/due to race conditions during cache clears or so (this is how I noticed it), and those really shouldn't be cached.. but there's no way to know if it's this or e.g. the database that's down :)
Comment #13
webchickBerdir suggested over in #2453351: Maintenance mode message ends up in page cache, served endlessly that this one should probably be critical as well, since it's a similar situation. Sounds like it to me, but marking for triage nevertheless.
Comment #14
BerdirI think the patch is still ready to go, if someone wants to cache error pages, they can now relatively easy do that with the max-cache changes and replacing the policy implementation, I think. It would probably also require a non-trivial implementation that implements something like an error page heat, to only cache the response if the site is actually down and returns a reproducable error and not just one of those race conditions in twig/caching, of which we have quite a lot right now.
Comment #16
dawehner... I'd honestly prefer simply adding a Default response policy to the already existing chain, instead of altering the chain.
Comment #17
BerdirFine with me, registering it directly as a private service.
Which works great btw, we should open a follow-up issue to do the same for node/image response and basic_auth request policies (where I forgot to do it when it was added). Saves us 2-3 roundtrips through the container service creation.
Comment #18
dawehnerMuch better!
Comment #19
BerdirOpened #2453711: Use public: false for request and response policy services.
Comment #20
alexpottThis issue addresses a critical bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 06d920a and pushed to 8.0.x. Thanks!
Comment #23
xjm