WordPress.org

Make WordPress Core

Opened 11 years ago

Closed 8 years ago

#14539 closed defect (bug) (wontfix)

Cache-Control / Expires headers not applied to files in Multisite files location

Reported by: spherical Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Multisite Keywords:
Focuses: Cc:

Description

First reported in Multisite forum and detailed there:

http://wordpress.org/support/topic/cache-control-headers-and-uploaded-files-not?replies=5

These file type accesses should return 304s according to the rules in .htaccess but consistently return 200, showing an incorrect Cache-Control header specification, instead of no specification at all--which is still undesired.

This occurs in two 3.0.1 Multisite installs on all blogs, domain mapped or not, but does not occur on any other domains on the server or in any other file locations in the WP tree (themes, etc.).

Initially, it was image files that I had identified this on but a subsequent check of a CSS file in the files/ location returned the same header that is set for (.php|.pl|.cgi) files; same as the image files do.

Apache 2.2.15, PHP 5.2.13, FreeBSD 7.2-STABLE, MySQL 5.0.90

Change History (10)

#1 follow-up: @andrea_r
11 years ago

Some additional info:

  • this seems to be occurring only on subfolder installs, for some people.
  • symptoms are unstyled subfolder blogs because the css file can't be found
  • if that works, the other lingering symptom is media uploads can't be found at the rewritten location

The general fix has always been to force mod_rewrite to read the htaccess file via AllowOverride FileInfo Options but I'm starting to see a few cases where that isn't helping any.

One user reported WPMU working fine on the server, they tore down the install, put in 3.0... and got these symptoms. So we could rule out the server there (I think).

Hope the additional info helps.

#2 in reply to: ↑ 1 @spherical
11 years ago

Replying to andrea_r:

Some additional info:

  • this seems to be occurring only on subfolder installs, for some people.
  • symptoms are unstyled subfolder blogs because the css file can't be found
  • if that works, the other lingering symptom is media uploads can't be found at the rewritten location

The general fix has always been to force mod_rewrite to read the htaccess file via AllowOverride FileInfo Options but I'm starting to see a few cases where that isn't helping any.

One user reported WPMU working fine on the server, they tore down the install, put in 3.0... and got these symptoms. So we could rule out the server there (I think).

Hope the additional info helps.

I'm not seeing how this relates to this problem. First, the situation I am reporting is on a subdomain install; not a subdirectory. Second, all of the files _are_ being found, no matter where they are. All of the blogs _are_ styled. There's no problem with that. In fact, I said in the ticket that themes are not affected by this at all. It is the non-respecting cache control directives on file types _only in the uploaded files location_ that is the problem, here, causing a 200 OK response, where it should be a 304 Not Modified because future expires is set for them.

#3 @dd32
11 years ago

  • Component changed from HTTP to Multisite

#4 @newzede
10 years ago

I've experienced the same issue with WP 3.2.1 Multisites SubDirectory.
Files from the files folder are sent with a Content-Length of 0.

curl -X GET -I http://www.example.com/wordpress/test/files/2011/10/ue.jpg
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2011 19:25:43 GMT
Server: Apache
X-Powered-By: PHP/5.3.2-1ubuntu4.10
Content-Length: 0
Last-Modified: Wed, 19 Oct 2011 12:56:36 GMT
ETag: "3b92507c5a7bc4a231512ad006dd2a10"
Expires: Sun, 25 Jan 2015 05:12:23 GMT
Connection: close
Content-Type: image/jpeg

But all files in wp-content/themes work.

 curl -X GET -I http://www.example.com/wordpress/test/wp-includes/images/admin-bar-sprite.png?d=11122010
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2011 19:28:21 GMT
Server: Apache
Last-Modified: Mon, 13 Dec 2010 20:35:28 GMT
ETag: "2922f7-2e1-49750a4fc0400;4b27fffad97c0"
Accept-Ranges: bytes
Content-Length: 737
Connection: close
Content-Type: image/png

Anyone found a solution?

#5 @GaryJ
10 years ago

I'm explicitly setting a access plus 1 year ExpiresByType header for image/* (also does the same with image/jpeg) yet a file being served from /files has an Expires header well beyond that (and in fact, breaks RFC specs because of it):

Date:Sat, 04 Feb 2012 04:19:29 GMT
Expires:Mon, 06 Apr 2015 14:06:09 GMT

.jpg and other images served from the theme folder have a correctly set Expires header.

#6 @Coopeh
9 years ago

  • Version changed from 3.0.1 to 3.4.1

Receiving the same issues using Nginx, although they are returning as 304 instead of 200 in my case. It will only take the global expires setting and not adhere to the one I've set for static objects, png/jpg/js etc.

#7 @SergeyBiryukov
9 years ago

  • Version changed from 3.4.1 to 3.0.1

Version number indicates when the bug was initially introduced/reported.

#8 @dd32
9 years ago

I'm explicitly setting a access plus 1 year ExpiresByType header for image/* (also does the same with image/jpeg) yet a file being served from /files has an Expires header well beyond that (and in fact, breaks RFC specs because of it):

This is because the files in /files are routed through ms-files.php, AFAIK, Nginx doesn't apply ExpiresByType to dynamic files and/or when a Expires-like header is already set.

Receiving the same issues using Nginx, although they are returning as 304 instead of 200 in my case. It will only take the global expires setting and not adhere to the one I've set for static objects, png/jpg/js etc.

This backs up my original thought, that per-type won't apply, but Global expires do (As they apply regardless of type). ms-files.php does return 304's however if the client supports ETags: http://core.trac.wordpress.org/browser/trunk/wp-includes/ms-files.php#L73 - ms-files.php also sets the Expires Header to +3.16 years (Ah how i wish that was 3.14..) which just so happens to be 100 million seconds.

IMHO, There isn't many things that can be done here, One could try preventing ms-files.php from outputting a Expires header, this might solve it, Alternatively, looking into bypassing ms-files.php (for more performance) might be a better idea: #19235

#9 @ocean90
9 years ago

  • Cc nacin added

#10 @jeremyfelt
8 years ago

  • Keywords dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Now that ms-files.php is off by default via #19235, this doesn't seem to be as big of an issue. 304s are generated if the client supports ETags. If that's not enough, we would need a way to maintain last modified information in a useable way.

Note: See TracTickets for help on using tickets.