| Project: | Drupal core |
| Version: | 6.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | litespeed, web server, webserver |
Issue Summary
Currently, .htaccess disables ExpiresActive for index.php. This should really apply to all .php files. The mod_expires stuff is intended for static files. PHP scripts should set their caching headers explicitly.
The current behaviour is a problem e.g. in this situation:
If you access update.php while your database is unavailable, you will get a WSOD, and the response will contain the header Cache-Control: max-age=1209600. Now, if you were accessing the server through e.g. an office proxy server, the proxy would cache that page, and you have to hit CTRL+F5 to force the proxy to fetch the page again (some proxies don't allow this).
This patch is inspired by Davy Van Den Bremt's suggested fix for #319420: Page cache makes browser cache pages for 2 weeks.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| mod_expires-1.patch | 941 bytes | Idle | FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mod_expires-1.patch. | View details |
Comments
#1
Yep. We definitely want that.
#2
By the way, this allows us to solve a bug in Drupal 6 where, in some configuration, mod_expires sets the expired header even for PHP generated content (see #319420: Page cache makes browser cache pages for 2 weeks).
If this goes in to Drupal 7, I'll requalify this as a bug and ask to backport to Drupal 6.
#3
I think this should be committed. For bonus, points, please extend the code comment explaining _why_ this should be disabled. That will make it more future proof. Let's do a quick re-roll with an extended comment, and mark it RTBC. As always, good job c960657.
#4
New patch with more comments.
#5
Committed to CVS HEAD. Thanks!
#6
For Drupal 6, this is a bug report. On some configurations, the text/html check doesn't work, because mod_expires is executed before mod_php.
#7
Here is a backport.
Note that it may have some impact on users who have put non-Drupal PHP files in a subdirectory. PHP scripts that output text/html will no longer have the “cache no longer than 1 second” restriction - the cache period is now decided by the browser. If a PHP script is used to output non-text/html data, e.g. images, these will no longer be cached for two weeks. But I guess this isn't too big an issue. In general, if a PHP script does not set cache headers itself, it cannot make to hard assumptions about how it will be cached in browsers and proxies.
#8
We really want that. This helps in some server configurations.
#9
Tested and +1 for 6.x
#10
I get error
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
#11
fender, are you talking about D6 or D7? Which Apache version are you using? Is anything interesting written to Apache's error log?
#12
i have drupal 6, is drupal 7 ready yet? :)
here is the bluehost apache specs
apache 1.3.37
#13
@fender
My guess is you patched the htaccess file by hand incorrectly. Can you double check & if your still encountering that error can you attach your htacces file?
#14
Committed to Drupal 6, thanks!
#15
Has anyone tested this new .htacess with LiteSpeed webserver?
#16
The new .htacess is not working on Mediatemple's Gridserver. I don't know whether this is a Mediatemple's bug or a Drupal 15 bug.
I am using the old .htacess file (Drupal 14 version) and my Drupal 15 site works properly with that.
Is there anything wrong with that?
#17
Re-test of mod_expires-1.patch from comment @comment was requested by Shellingfox.
#19
I'm using shared web hosting and I have
AddHandler phpini-cgi .php .htmAction phpini-cgi /cgi-bin/php5-custom-ini.cgi
in my .htaccess for setting php variables.
And due to this mod_expires settings don't work.
Please help.
Thank you.
#20
@vnb
Change this
<FilesMatch \.php$>to this
<FilesMatch (\.php|\.htm)$>#21
@mikeytown2
Thank you for suggestion. Although that doesn't work, the solution was close :
<FilesMatch "\.(php|cgi)$">hooray!
#22
subscribing
#23
Setting this back to fixed since it was already committed (#14).
#24
Automatically closed -- issue fixed for 2 weeks with no activity.