[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 drzraf):

 Replying to [comment:9 dd32]:
 > > Which browsers are affected?
 > Any browser which respects a server-sent expiry, noting that WordPress
 doesn't send those, but rather the sever configurations.

 Ok, so the browsers are assumed to respect RFC-2616 and to behave
 correctly to servers-originated headers.
 They are not part of the issue then.

 > > What/Who may configure *by mistake* WP to set a too-large expire time?
 > WordPress developers and users are not the ones who configure the server
 in most cases. Many WordPress sites get installed behind a CDN (the user
 may not even realise that, or might not understand the implications of
 it), etc.

 AFAIK a CDN do not pose issues by themselves that would make cache-busting
 necessary.
 Users may have limited control over configuration *BUT* any
 RFC2616-compliant caching-proxies offer a form of control using headers.
 That's the best/well-defined form of control over caching-proxies and
 something WordPress can do.


 > It's also not uncommon (unfortunately) to find a declaration such as
 `ExpiresByType text/css "access plus 30 days"` on some preconfigured
 servers, which the end-user can't modify.

 = How is it a problem? Isn't intended?
 These are CSS (from core, theme, plugin, or uploaded by the user in some
 way). Server configuration says there expire in 1 month and the browser
 cache them as it should. Any attempt to circumvent this is just trying to
 discard RFC2616. Why not trust sysadmin by default.

 = How is it a problem (bis)? Isn't configurable after all?
 Citing [https://httpd.apache.org/docs/2.2/mod/mod_expires.html#AltSyn
 Apache2 documentation]:
 > When the Expires header is already part of the response generated by the
 server, for example when generated by a CGI script or proxied from an
 origin server, this module does not change or add an Expires or Cache-
 Control header.
 In such a configuration assets maybe routed to index.php (rather than
 having `RewriteRule -f` bypassing the `index.php` entry-point) so that PHP
 can force a short Expire time.
 (letting workarounds to buggies configurations)


 = Cache-busting does not give a (strong) guarantee to solve the issue.
 In case the end-user has no access to webserver configuration, he does not
 have access either to the fact that `foo.css?ver=4.2` could be given a
 text/css mime-type and thus be cached as well. Multiple resources will be
 cached for 1 month rather than resource being refreshed when needed.
 Freshness guarantee is strong for Apache2 webserver since it won't cache
 these entities. But is the the current cache-busting workaround
 Apache2-centric? (at least it seems like)

 = Cache-busting is a workaround rather than the correct cache-refreshing
 method
 Mostly this is saying:
 - css may needs refresh now
 - wait user to hit index.php again
 - put some css-suffixing to css links in the HTML
 - expect browser to send a GET for these URL
 - expect the server to invalidate it's cache since a new query-string was
 appended (or, more exactly, cache the new version under a new key/URI)

 This is a very long, painful and indirect workaround for invalidating
 caches while there are a so 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)
 This can be done by the browser (hard-refresh) or by the "end-user" (the
 WordPress instance/customer) using `file_get_contents()` & co and this
 is... **standart**.

 = How many users the current cache-busting method accounts for?
 As a complement of my above question of "how is it a problem that a css
 would be cached 1 month?", I would curious about what's the percentage of
 users affected, I mean users:
 - behind a caching-proxy? --- 20%?
 - that they don't control? ----- 50% of the above?
 - and is misconfigured? ------ 10% of the above?
 - and misconfigured in a way it cause problems to WP? X% (I don't know
 what kind of problem)
 and I would even add:
 - where the proxy cache can't be invalidated using standard headers (here
 we hit 0%)

 Sure you may have better statistics available, but I bet we are talking
 about < 0.2% of the users, while the hypothetical 20% of the total user-
 base are given a non-functional cache from the default installation.
 And if we even consider only Apache2 setups, I think that more 50% of the
 people have an "AllowOverride" allowing users to play with mod_expire in
 their htaccess.

 Or should we assume there are more misconfigured caching-proxies than
 well-configured caching-proxies?


 In the end, if cache-busting is necessary (when ?) to avoid problems (of
 what kind?), why not prefer a standard cache-busting method (called "cache
 invalidation") rather than a dirty and invasive custom one which brings
 more than one side-effects?


 > WordPress is rarely run in a scenario where the configuration of all the
 moving parts is perfect, that's why WordPress "just works" almost anywhere
 - it's amazing for an end-user, yet also introduces extra restrictions
 upon what we (the WordPress project) can reasonably do.

 Yes but having assets suffixed with a query-string in core is a way to
 assume that its serves more people than people it loosen. Let's
 investigate whether it's true or not.
 - We can enumerate buggy setups and see how real and/or mainstream they
 are.
 - Then we can consider whether cache-busting URL-suffixing could/should be
 done as a plugin
 - and/or discuss alternatives
 - ...
 But I can't argue about whether WordPress default configuration should
 match one given buggy cache setup theoretically because it goes down to
 politics.

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