[wp-trac] [WordPress Trac] #25072: Send no-cache response header from wp-cron.php requests

[WordPress Trac]

#25072: Send no-cache response header from wp-cron.php requests
--------------------------+-----------------------------
 Reporter:  westonruter   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Cron          |    Version:  trunk
 Severity:  minor         |   Keywords:  has-patch
--------------------------+-----------------------------
 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.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25072>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software