setting header cache-control to no-store for aggregated css

Created on 14 March 2024, 9 months ago

I am using core CSS aggregator. The site is having static pages only. There are two aggregated CSS generated for each cache clear.
Out of which first css is always having a header cache-control setting to no-store, private while other is setting to provided max-age.
The .htaccess file is already having below code snipped from core but not working correctly for first css file only. Due to this issue while loading the css, there is unnecessary hit to drupal server, causing performance issue.


# Enable expirations.
ExpiresActive On

# Cache all files for 1 year after access.
ExpiresDefault "access plus 1 year"


# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior. This may
# fail if an error occurs early in the bootstrap process, and it may cause
# problems if a non-Drupal PHP file is installed in a subdirectory.
ExpiresActive Off

🐛 Bug report
Status

Active

Version

10.1

Component
Asset library 

Last updated 2 days ago

No maintainer
Created by

🇮🇳India mahesh.umarane

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @mahesh.umarane
  • 🇮🇳India mahesh.umarane

    I have also tried below alternative but it's still not working,

    <FilesMatch "^(css|js)_[A-Za-z0-9-_]{43}.(css|js)(\.gz)?">
      # No mod_headers
      <IfModule !mod_headers.c>
        # Use Expires Directive.
        <IfModule mod_expires.c>
          # Do not use ETags.
          FileETag None
          # Enable expirations.
          ExpiresActive On
          # Cache all aggregated css/js files for 480 weeks after access (A).
          ExpiresDefault A290304000
        </IfModule>
      </IfModule>
    
      <IfModule mod_headers.c>
        # Set a far future Cache-Control header to 480 weeks.
        Header set Cache-Control "max-age=290304000, no-transform, public"
        # Set a far future Expires header.
        Header set Expires "Tue, 20 Jan 2037 04:20:42 GMT"
        # Do not use etags for cache validation.
        Header unset ETag
      </IfModule>
    </FilesMatch>
    
  • This as written is not critical priority. I think it may be a duplicate.

  • Status changed to Postponed: needs info 9 months ago
  • Please use the issue template and in particular document the steps to reproduce this bug.

  • 🇮🇳India mahesh.umarane

    Here are the steps to reproduce.
    1. Enable the CSS aggregator
    2. Go to site homepage and press F12 to see the Network tab
    3. Select CSS in Network tab
    4. Select 1st CSS and click on Header tab
    5. For non-logged in user, Cache-control should be Public or with max-age as set in .htaccess file
    6. But it's showing cache-control: no-store, private

  • I cannot reproduce this bug as written. Drupal by default has ExpiresDefault "access plus 1 year" which works as expected by setting max-age in the cache-control header in every site I've built.

    If this is a bug and not a platform setup on your end there must be more steps to reproduce.

  • 🇬🇧United Kingdom longwave UK

    This happens the first time a file is generated and served directly by the new asset aggregation code in 10.1, there is a comment in the code about it somewhere. Once the file is written to disk and served directly by Apache it doesn't happen.

  • Oh, that. Is this a duplicate of 🐛 Compressed aggregates not delivered on first request Needs work or similar?

  • 🇮🇳India mahesh.umarane

    This i have already added in my .htaccess code ExpiresDefault "access plus 1 year"
    For me, it's not only for first time, it's always happening.

  • 🇺🇸United States hablat

    We are also running into this, and it seems for us the cache control is set to no-store when you request an aggregated file that Drupal does not expect. For example if this is one of the JS requests that drupal generates on page load
    /sites/my.site.com/files/js/js_k7uMCXgc43aWXEacSj8oD_I5kXAJJ7IABhs2MRXtPEg.js?scope=footer&delta=3&language=en&theme=transpo&include=eJx1UtF2wyAI_SEXX7b9jgeVJG4oHjDrsq-f6dI2a7cXDtwrcEHwswm4MSFFF1GDpNoSF4t_4y6omol5InRQgNaWgtp7wFQQmATqrG6SFO1dPHjmpr1BfTZ1kamnvsGnq8IBVVlskzRNKO5MGl21YbYeFE3k5kLuLYk90JO2lVKZrvDIpcEJlTO6V3Nt4zyIJL7P6lTR-i_8u1jfSGffbZSlAg17aAITQdXkicO7DSzYX1Yo0e1MH47I_mBPF-wgjZIXkNVekUfZyosEdNplbUt6fHBU-nLVf5_211wv5iPhSe3ZDpnjQnj4vsu0N2RYSl08JZ0xPgopHPtsBF99ns3uPjHE3a1M65iI9jAQqPZq7UIL56SXGgLj7p3Q193dLsj0nL7usx0QdPu2I7Sd6TFuM2b8hWRIZdBKqZmFWspYlp-j11s8Q_bbBcoN4nEMUD5Ah7roHPlUvgHS9kjk

    If you change the file name to something random, but keep everything else. Drupal will respond with a 200 and a no-store cache control. example

    /sites/my.site.com/files/js/js_RANDOMFILENAME.js?scope=footer&delta=3&language=en&theme=transpo&include=eJx1UtF2wyAI_SEXX7b9jgeVJG4oHjDrsq-f6dI2a7cXDtwrcEHwswm4MSFFF1GDpNoSF4t_4y6omol5InRQgNaWgtp7wFQQmATqrG6SFO1dPHjmpr1BfTZ1kamnvsGnq8IBVVlskzRNKO5MGl21YbYeFE3k5kLuLYk90JO2lVKZrvDIpcEJlTO6V3Nt4zyIJL7P6lTR-i_8u1jfSGffbZSlAg17aAITQdXkicO7DSzYX1Yo0e1MH47I_mBPF-wgjZIXkNVekUfZyosEdNplbUt6fHBU-nLVf5_211wv5iPhSe3ZDpnjQnj4vsu0N2RYSl08JZ0xPgopHPtsBF99ns3uPjHE3a1M65iI9jAQqPZq7UIL56SXGgLj7p3Q193dLsj0nL7usx0QdPu2I7Sd6TFuM2b8hWRIZdBKqZmFWspYlp-j11s8Q_bbBcoN4nEMUD5Ah7roHPlUvgHS9kjk

    This is an issue for us because we have a use case where other sites reference our assets and may not have the update js/css aggregated links right away. And this causes a lot of uncached requests hitting all the way to origin. Specifically if those sites have bots crawling them

  • 🇳🇿New Zealand quietone

    Drupal 10.1.x is no longer supported. Does this problem occur on a currently support version of Drupal?

Production build 0.71.5 2024