[wp-trac] [WordPress Trac] #51831: WP REST API and Caching Issue
WordPress Trac
noreply at wordpress.org
Fri Nov 20 09:40:29 UTC 2020
#51831: WP REST API and Caching Issue
--------------------------+-----------------------------
Reporter: mguenter | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: REST API | Version: 5.5.3
Severity: normal | Keywords:
Focuses: rest-api |
--------------------------+-----------------------------
''A follow-up to https://core.trac.wordpress.org/ticket/39861, cause I can
not change the WordPress version to 5.5.3.''
Hey @joehoyle and @lukecavanagh,
I just came across this ticket because I have a similar issue. We have
implemented a dashboard in a WordPress submenu page. Imagine the following
scenario:
1. Open the dashboard
2. JavaScript is fetching data via `GET` from a WP REST API endpoint
3. Click on another submenu, e.g. media library
4. Use the back button from the browser
5. Check the network log and you will see, that the WP REST API request
got cached (`200 OK (from disk cache)`)
[[Image(https://i.imgur.com/9z0i3bT.png)]]
Tested on Chrome, but I think this happens on all browsers.
**How can this be fixed?** Using the following header disallows the
browsers to cache the response:
`Cache-Control: no-cache, no-store, must-revalidate, max-age=0`
Add `no-store` directive, see also https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Cache-Control and
https://www.mixmax.com/engineering/chrome-back-button-cache-no-store/
> The solution? Add the no-store cache directive. It tells the browser to
really not store anything at > all. So this works, and clicking the back
button in Chrome will never serve up cached content: [...]
If you fix this, you need to be careful, because the directive should
probably only be added on WP REST API calls.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/51831>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list