We have been seeing an intermittent issue on some 6.x development sites in which sometimes one stale CSS is served one page load, sometimes another, and sometimes fresh CSS.

Finding that disabling browser caching fixed this issue and watching behavior across page reloads when compared with source, it appears that the issue is occuring when a query_string value that has been used in the past to access a site is used again. For instance, if over the course of loads the following link sources are used for a given CSS file:

http://client.com/sites/all/themes/custom/clienttheme_omega/css/style.css?F
http://client.com/sites/all/themes/custom/clienttheme_omega/css/style.css?A
http://client.com/sites/all/themes/custom/clienttheme_omega/css/style.css?V
http://client.com/sites/all/themes/custom/clienttheme_omega/css/style.css?F

The version served the second time "F" is used as the query_string value in drupal_get_css will be served from the browsers cache and may be stale if changes have been made in the interim.

it appears that a code-level fix would be to use a longer query_string. We can get around this in development by disabling or clearing our browser caches and in production by enabling CSS aggregation, but this approach may not be feasible for all impacted by this behavior (live sites not using aggregation, for instance).

Could a functin such as rand be used to cheaply generate this longer key in _drupal_flush_css_js and the one char substr in drupal_get_css removed?

Is the 1 char length of query_string mainly due to bandwidth considerations or is there another reason?

Thanks.

Comments

damien tournoud’s picture

damien tournoud commented
Component: drupal.module » base system

This query-string suffix should only change very seldomly. In core, it changes when you hit the "clear all caches" button, or when you visit the info page of update.php. In contrib, it also changes when you hit the "Flush all caches" options of Devel and Admin Menu.

None of them impact any production site, and I never saw this happening in development either, even if some browsers (especially webkit-based) are *really* picky with their caching of CSS and Javascript files.

Would it be possible that something is clearing those cache way to often in your development environment?

ethanw’s picture

ethanw commented
Component: base system » drupal.module

One additional note: while this bug is related to discussions at http://drupal.org/node/242875 and http://drupal.org/node/199946 it doesn't look like it is specifically addressed in those posts

Gábor Hojtsy does note the concern that the CSS URL be "short enough query string to not mess up with the HTML page that much", so one question would be how much more than one character long this could be. If we can use 3 characters, using rand along with base 32 would give many more possible strings:

base_convert(rand(0,32768),10,32);

ethanw’s picture

ethanw commented

Thanks Damien, my above comment was posted before seeing your reply.

We clear the caches on our sites quite frequently when in development mode, as there may be a number of developers and themers working simultaneously. This happens mostly as we add views templates, etc. So I would say it's more a case of cache's being cached "frequently" then "too frequently" :).

Many of us are using Webkit browsers for testing, so you're comment is in line there as well.

All that said, it seems that using a slightly longer string would avoid these issues altogether, provided it is not infeasible for some other reason.

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.