WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 6 months ago

#39861 reopened defect (bug)

WP REST API and Caching Issue

Reported by: sckmkny Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7.2
Component: REST API Keywords:
Focuses: Cc:

Description

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

Change History (4)

#2 @joehoyle
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

@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!

#3 @TimothyBlynJacobs
6 months ago

#51831 was marked as a duplicate.

#4 @mguenter
6 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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))

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.

Note: See TracTickets for help on using tickets.