[wp-trac] [WordPress Trac] #29201: File versioning should not use query strings, but rename the filename to allow caching

[WordPress Trac]

#29201: File versioning should not use query strings, but rename the filename to
allow caching
---------------------------+--------------------------
 Reporter:  benoitchantre  |       Owner:
     Type:  enhancement    |      Status:  closed
 Priority:  normal         |   Milestone:
Component:  Script Loader  |     Version:  3.9.1
 Severity:  normal         |  Resolution:  wontfix
 Keywords:                 |     Focuses:  performance
---------------------------+--------------------------

Comment (by mdawaffe):

 Replying to [comment:6 drzraf]:

 I'm not sure what problem you're trying to solve.

 > Refreshing downstream proxies is as easy as issuing a "Cache-Control" or
 "Pragma", and the webserver as well as the client:
 > If a resource changes, just trigger
 > {{{
 > wp_remote_get($post_url, [ 'blocking'  => false 'headers'  => array
 ('Cache-Control' => 'no-cache') ]);
 > }}}

 ...

 > simpler solution:
 > * fire a GET with `Cache-Control: no-cache`, or `Pragma: no-cache` (or
 both if you want) to said resource and forget (you can be sure the proxy
 will kindly refresh its cache)

 How does this help? There's no way to know what proxies there are between
 some arbitrary visitor and your site.  In any case, browsers will still
 have the old version cached.

 To restate what's been mentioned above, a pretty common setup is for the
 webserver to issue long expiry times (let's say 1 year). In this setup:
  * Browser makes request to style.css?ver=1
  * Browser (and potentially proxies in between) cache style.css?ver=1
  * When the underlying style.css resource changes, the version is bumped
 (by core in core's case or by the plugin/theme in that case).
  * Browser makes new request to style.css?ver=2
  * Browser (and potentially proxies in between) cache style.css?ver=2

 There's no way for the server to clear unknown proxy caches. There's no
 way for the server to clear the browser cache. Instead, the server tells
 the browser to request a new resource (by altering this query string
 parameter).

 Plugins can, of course, change the core behavior.  For example, I know
 some sites remove the `?ver=` parameter and replace it with a query string
 parameter that corresponds to the `mtime` of the file. This mtime method
 is more robust but is hard to implement correctly on sites served by many
 webservers. It also may be non-performant on many hosts.  Core's `?ver=`
 method is good compromise that works pretty well most places.

 > What/Who may configure *by mistake* WP to set a too-large expire time?

 I don't think this long cache expiry choice is a mistake.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29201#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform