WP REST API and Caching Issue

[sckmkny]

It appears that the current implementation of the WP REST API uses the following cache control header:

cache-control:no-cache, must-revalidate, max-age=0

The problem is that some providers, e.g., SiteGround, also tack on a bogus last modified header:

last-modified:Thu, 01 Jan 1970 00:00:00 GMT

This combination causes the browser to add a "if-modified-since" header to subsequent API call and resulting with a 304 response (in this case NGINX at SiteGround). At the point, you continually get stale results from the API.

The fix is to also add a "no-store" to the API response.

Cache-Control: no-cache, no-store, must-revalidate

For reference:

​https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

[lukecavanagh]

@sckmkny

That might be set from

https://core.trac.wordpress.org/browser/tags/4.7.2/src/wp-includes/functions.php#L1102

[joehoyle]

@sckmkny is this for an authenticated request? We don't send no-cache headers on anonymous requests, for example:

> http https://demo.wp-api.org/wp-json/wp/v2/posts
HTTP/1.1 200 OK
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
Allow: GET
Cache-Control: max-age=300, must-revalidate
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=UTF-8
Date: Sun, 26 Mar 2017 01:56:55 GMT
Last-Modified: Sun, 26 Mar 2017 01:56:55 GMT
Link: <https://demo.wp-api.org/wp-json/wp/v2/posts?page=2>; rel="next"
Server: nginx/1.4.6 (Ubuntu)

As for siteground returning the bogus last-modified, I don't know why they would be doing that but I think that might be an issue on their end.

cache-control:no-cache, must-revalidate, max-age=0 should absolutely not cause a last modified to be that, so it might be better to reach out to their support. We already send a last modified of the current date.

Going to close out, but re-open if it seems I missed something!

[TimothyBlynJacobs]

#51831 was marked as a duplicate.

[mguenter]

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

Check the network log and you will see, that the WP REST API request got cached (200 OK (from disk cache))

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.

[johnbillion]

Let's see if we can tackle this along with #21938 and #57627

[johnbillion]

I didn't have a chance to work on this for 6.3.