* Go to login page: GET request at /user/login has header: cache-control: max-age=1800, public Test scenario: logged in then logged out, "Back" does not show authenticated cache Note: when testing locally, ensure you do not have "Vary: Cookie" as a header in the server response. Testing results on Drupal 8.9.1 using Firefox 78.0.2. This makes must-revalidate redundant.Ĭurious what Page Cache maintainer thinks! No-cache allows caching by proxies but requires revalidation. IOW: no-store breaks the browser's "back button cache".īased on my digging, this seems accurate though: There's a lot of dark magic and obscure knowledge in Cache-Control response directive land. ![]() In my experience, it's almost never quite this simple. The test expectations prove this, and you even quote that at the beginning of the issue summary. Private is AFAICT only added for authenticated users. That's also what \Drupal\Core\EventSubscriber\FinishResponseSubscriber::setCacheControlNoCache() in D8/D9 does. No-cache, must-revalidate originates from Drupal 7. When this fix is applied, what will change about how Drupal is cached? Is there a change to the browser's back button? Is that change true for all browsers? I attached a patch but didn't write or update any tests. This is fixed by setting the 3rd parameter to TRUE. private and no-cache are set at the same time because $response->headers->set() appends headers by default.An alternative solution is to change the implementation of setCacheControlNoCache(), and not introduce setCacheControlNoStore(). With my patch applied, setCacheControlNoCache() is no longer used in core, but given that it is a protected method, it might be used by contributed modules. I fixed the implementation of setCacheControlNoCache() and added a new function setCacheControlNoStore().No-store means that the resource can't be stored by any cache, including the browser's cache. It is better to use the following header: ![]() This is at odds with no-cache which allows proxies to cache the resource, as long they always revalidate first. private disallows caching by proxies (only the browser can cache).no-cache allows caching by proxies but requires revalidation. ![]() In other words, these headers are at odds with one another: Varnish, CDN), but that it is ok for a browser to cache the resource. private means that the resource can't be cached by proxies (e.g.The name of the header is somewhat counter-intuitive. no-cache means the resource can be cached, but that it must be revalidated each time before using it.It needs to first revalidate the request with the origin server. must-revalidate means that the cache must not use the resource after it becomes stale. ![]() The problem is that this is a bad way to tell a browser and any proxy cache not to cache a page: You can also see this in action by inspecting the headers of. This is also what happens when you use the page cache kill switch: \Drupal::service('page_cache_kill_switch')->trigger(). $this->assertEqual($this->drupalGetHeader('Cache-Control'), 'must-revalidate, no-cache, private', 'Cache-Control header was sent') This appears to be the intended behavior per core/modules/page_cache/tests/src/Functional/PageCacheTest.php: // Check that authenticated users bypass the cache. When using the page cache, we will generate the following HTTP headers when we need to by-pass the cache:Ĭache-Control: must-revalidate, no-cache, private
0 Comments
Leave a Reply. |