Send no-cache response header from wp-cron.php requests
|Reported by:||westonruter||Owned by:|
In high-scale WordPress installs, it is common to enable DISABLE_WP_CRON and then have a system cron ping wp-cron.php?doing_wp_cron every minute. When working on a site with DISABLE_WP_CRON, we recently ran into a situation where future-published posts were consistently missing their schedule for several minutes. It turns out that the network architecture routed requests through Pound and then Varnish before hitting the web server, including requests originating on the server itself.
Because of the default proxy cache configuration, the requests to wp-cron.php were getting served from the cache without hitting WordPress, so the scheduled tasks were not getting executed. A workaround was put in place to add a timestamp cache-buster (i.e. wp-cron.php?doing_wp_cron&1283712312), and then we worked out a more elegant solution with a mu-plugin which did nocache_headers() if DOING_CRON. It seems the best solution is to just always send no-cache headers from wp-cron.php itself, as I can't imagine a situation where responses should be cached (except maybe with a max-age=60).
In addition to the default no-cache headers that WordPress sends, we also included a Surrogate-Control: no-cache header for caching proxies to specifically target.
So to summarize: I propose that wp-cron.php send no-cache response headers.
Change History (6)
comment:3 c3mdigital — 4 months ago
- Severity changed from minor to normal
- Version changed from trunk to 2.1