WordPress.org

Forums

Cache-Control headers and uploaded files - Not! (7 posts)

  1. spherical
    Member
    Posted 5 years ago #

    Natty to describe problem that I think is related to ms-files.php new in WP3.x and how it handles uploaded files. First off, this worked as expected in WP < 3.x.

    Set Cache-Control headers in .htaccess using FilesMatch, with or without using Expires headers (here included):

    # 1 YEAR
    <FilesMatch "\.(ico|png|jpg|gif|pdf|swf|flv|doc|mp3|mp4|mov|avi)$">
    ExpiresDefault A29030400
    Header set Cache-Control "max-age=29030400"
    </FilesMatch>
    
    # 6 WEEKS
    <FilesMatch "\.(css|js)$">
    ExpiresDefault A3628800
    Header set Cache-Control "max-age=3628800, proxy-revalidate"
    </FilesMatch>
    
    # 1 HOUR
    <FilesMatch "\.(html|xml|txt)$">
    ExpiresDefault A3600
    Header set Cache-Control "max-age=3600, private, must-revalidate"
    </FilesMatch>
    
    # NO CACHE
    <FilesMatch "\.(php|pl|cgi)$">
    ExpiresActive Off
    Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
    </FilesMatch>

    Check the page loading with FireBug and ONLY media files loaded from:
    http://domain.tld/files/YYYY/MM/filename.ext

    show the Cache-Control as being
    "private, no-cache, no-store, proxy-revalidate, no-transform"

    instead of
    "max-age=29030400"
    as it should be. It's as if the FilesMatch rules are being re-written, ignored or a .php extension is being appended if files are found in the upload location, because they are not being recognized as having a Cache-Control specification for their type. The specification for the
    php|pl|cgi
    files is being applied instead, which points to a .php extension and possibly a dreaded version being added to the filename defeating the rule.

    WP theme files and files loaded from an external domain all exhibit the correct Cache-Control headers. Only the upload location exhibits this anomaly and they are the only ones served through ms-files.php.

    I then checked this on a second WP3.x install that does not have the domain mapping plugin running and the blogs over there do the same exact thing, so it's not the domain mapping plugin getting in the mix.

    All other domains on the server not using WP3.x work as expected, exhibiting the correct Cache-Control headers on the correct file types.

    Looking at the ms-files.php code, I see lines in there attempting to set Expires, Last-Modified and ETag caching headers, where a server admin would set them specifically elsewhere. Don't see anything related directly to Cache-Control but the above code, or code in wp-load.php could be messing with already set header specifications.

  2. trac ticket time?

  3. spherical
    Member
    Posted 5 years ago #

    Hi Andrea.

    Seems like it might be. I'm surprised no one else has noticed this. Of course, someone has to be first, I guess.

    Messing around with minimizing DNS lookups after reading a thread where you instructed where to change the domain in SuperAdmin > Sites > Edit, I found that if there are CSS files out in blogs.dir/ID#/files/land that they, too, inherit the wrong Cache-Control headers; same as the images. So, it appears that anything out there suffers the same fate.

  4. You know what? This may relate to issues where people have unstyled subfolder blogs too. Forcing mod_rewrite to read the htaccess file helps in most cases, but not a couple tricky ones.

  5. spherical
    Member
    Posted 5 years ago #

    unstyled subfolder blogs ?

    force mod_rewrite to read the htaccess file ?

    Completely unsure about the first and I thought that mod_rewrite read htaccess by default. That's where it gets its rules; or do you mean make WP internal rewrites use htaccess instead? If the latter, just in case it's needed someday, how does one tell WP to do that?

  6. Completely unsure about the first and I thought that mod_rewrite read htaccess by default.

    Nope, not unless Apache is specifically told to do. It's off by default then allowed for specific vhosts.

    If seen some where it trickled down but only so far.

    I don;t mean to run you off on a tangent tho. :D

  7. volleyballmaniac
    Member
    Posted 4 years ago #

    I'm on version 3.1.3 (Multi-site), and I'm experiencing the same issues mentioned above.

    Can anyone please point me to the Trac ticket for this?

    I looked but could not find any related to it.

Topic Closed

This topic has been closed to new replies.

About this Topic