Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In certain circumstances, adding the css_js_query_string value can cause performance problems, especially in situations where reverse proxies are used. It would be useful to have a way of disabling this.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drupal-n772328-d6_skip_css_js_query_string.patch | 1.76 KB | DamienMcKenna |
Comments
Comment #1
DamienMcKennaHere's a patch that provides a new variable, "skip_css_js_query_string", that will skip adding the query string to the JS and CSS file paths. This variable defaults to FALSE.
FYI I'm providing a D6 patch for now, will provide a D7 patch later.
Comment #2
DamienMcKennaFYI corresponding patches have been supplied for the Zen theme for all three active branches: [#http://drupal.org/node/772234]
Comment #3
c960657 CreditAttribution: c960657 commentedUnder which circumstances is the query string a performance problem?
Comment #4
DamienMcKennaThe primary use case I was presented with was when using a reverse proxy, e.g. Varnish, to cache the compiled JS & CSS, these services usually are configured to not cache URLs with query strings included.
Comment #5
c960657 CreditAttribution: c960657 commentedIs there any good reason to configure you reverse proxy that way if it only proxies a Drupal site? The mod_expires rules in .htaccess instructs Apache to send cache-friendly HTTP headers for static files, so if the reverse proxy chooses to ignore these if the URL contains a query string, I'd say the proper solution is to fix the reverse proxy configuration.
Comment #6
DamienMcKennaDouble-checking with our server admin - some reverse proxy engines, e.g. Squid, are not intelligent to handle it properly so a patch like this is needed. Other reverse proxy engines, like Varnish, are flexible enough to handle more complicated settings like this and so for these the patch isn't needed. For people who use Squid this patch could help.
Comment #7
c960657 CreditAttribution: c960657 commentedThis thread covers Squid's default behaviour now and historically:
http://www.mail-archive.com/squid-users@squid-cache.org/msg57407.html
http://www.mail-archive.com/squid-users@squid-cache.org/msg57480.html
AFAICT older versions of Squid did not cache URLs with a query string by default, but it could be configured to do so. Newer versions of Squid should cache these URLs just fine, if they are served with proper Cache-Control headers. I don't have a Squid at hand for testing, but I don't remember any problems of that kind when I was administering Squids a while back.
Comment #8
DamienMcKennaThanks for the insight. I guess this status update covers it then?
Comment #9
c960657 CreditAttribution: c960657 commentedAs mentioned in #721400-72: Order JS files according to weight, don't change filenames for aggregated JS/CSS some proxies of the ISP/company kind (not reverse proxies) may be configured like the very old versions of Squid, so they wont cache URLs with a query string in them. When Drupal add a query string to the JS and CSS files, users of these misconfigured proxies will see a slightly decreased performance, though not worse than if they accessed the internet directly (without the proxy) on the same internet connection. If they are on a very bad internet connection, you would expect them to configure their proxy to cache as much as possible. I'd expect these misconfigured proxies to be rather rare, so I don't think it's worth adding extra code to Drupal.
In other words: Yes, I agree that it's a won't fix :-)