Last modified: 2011-02-07 02:52:19 UTC
Every time one runs update.php, there is a side effect of causing the >Last-Modified: Thu, 03 Feb 2011 00:20:37 GMT HTTP header of Special:RecentChanges to get reset, and probably also that of RSS feeds. Understand that many programs e.g., WWWOFFLE, monitoring this date will thus cause a false notification to their user, who then looks to find nothing changed in RecentChanges. Also notice that on high use wikis like Wikipedia, one wouldn't be aware of the problem, but on low use wikis, one certainly will. Don't just assume that Last-Modified should be updated without a valid reason. I won't even get into the waste that is caused by resetting the Last-Modified header on a RSS feed.
Can not reproduce on trunk. (While once i disable $wgUseRCPatrol, which messes with last mod header) However, if the update script makes any edits (and those edits get included in the RC, perhaps hidden as bot), which might happen if it deletes old messages that are the same as the default (but that'd only be updating from a really old version), that would obviously reset the timestamp as it should) >Understand that many programs e.g., WWWOFFLE, monitoring this date will >thus cause a false notification to their user, who then looks to find >nothing changed in RecentChanges. The last-modified date could mean anything changed, not necessarily someone edited. For example installing an extension (which will touch the modified time on LocalSettings.php, and in the default config update $wgCacheEpoch) will also reset this date. Changing your user prefs will also update this date (because that can affect what the RC looks like). If you want to know when the last person edited, you should use the date of when the last person edited, not the date that page changed.
I see, I need to adapt my LocalSettings.php to the new stuff in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/77878 .
Perhaps add some words of warning like: --- /home/jidanni/mediawiki/includes/DefaultSettings.php 2011-02-04 11:12:47.000000000 +0800 +++ /tmp/DefaultSettings.php 2011-02-04 18:06:21.923788222 +0800 @@ -1688,9 +1688,15 @@ * to setting $wgCacheEpoch to the modification time of LocalSettings.php, as * was previously done in the default LocalSettings.php file. * - * On high-traffic wikis, this should be set to false, to avoid the need to + * On high-traffic wikis, this should be set to false, to avoid the need to * check the file modification time, and to avoid the performance impact of - * unnecessary cache invalidations. + * unnecessary cache invalidations. + * + * On low-traffic wikis where LocalSettings.php may be edited more + * often than any article, if this variable is set to true, users + * using programs that monitor the Last-Modified HTTP header of + * Special:RecentChanges and its RSS feed will detect a change only to + * find none! So consider setting it false on low-traffic wikis too! */ $wgInvalidateCacheOnLocalSettingsChange = true;
/me votes WONTFIX. That would also stop cache invalidation for pages in general, which will cause people to get confused when they edit LocalSettings.php and none of the settings changes seem to get applied. This also doesn't have anything to do with your original bug, since the update script doesn't touch LocalSettings.php.
No, we're not adding that comment.
(In reply to comment #4) > That would also stop cache invalidation for pages in > general, which will cause people to get confused when they edit > LocalSettings.php and none of the settings changes seem to get applied. That should also be mentioned -- full disclosure of all pros and cons. > This also doesn't have anything to do with your original bug, since the update > script doesn't touch LocalSettings.php. I updated the bug upon finding the real culprit. A hard thing for one to find without the aforementioned full disclosure. But have it your way.
But it wasn't even the real culprit. It's one of several other potential culprits in addition to the real culprit. Changing that setting won't solve the problem you originally reported.
(In reply to comment #7) > Changing that setting won't solve the problem you originally reported. Did too! After changing $ diff -U0 OldLocalSettings.php LocalSettings.php -$wgCacheEpoch=max($wgCacheEpoch,gmdate('YmdHis',@filemtime(__FILE__))); +$wgInvalidateCacheOnLocalSettingsChange=false; I now get real dates when testing with: for i in abj.jidanni.org transgender-taiwan.org radioscanningtw.jidanni.org do HEAD -PS http://$i/index.php?title=Special:RecentChanges; done| grep Last-Modified Last-Modified: Tue, 01 Feb 2011 12:58:14 GMT Last-Modified: Sun, 09 Jan 2011 01:24:14 GMT Last-Modified: Sun, 16 Jan 2011 15:08:00 GMT Instead of all three Wiki Family members giving the same Last-Modified: Thu, 03 Feb 2011 00:20:37 GMT which is what I get if I left things as they were.
Yeah, but other things can still change the Last-Modified date on Special:RecentChanges, causing WWWOFFLE to inform people of an update when there is none. You shouldn't rely on that.
(In reply to comment #9) > Yeah, but other things can still change the Last-Modified date on > Special:RecentChanges, causing WWWOFFLE to inform people of an update when > there is none. You shouldn't rely on that. Cough up the facts! I want to root out and prosecute each of these illegal causes. I can't stand being suckered into checking RecentChanges only to find no change. On high use wikis this is never a problem, but on low use wikis, a daily false alarm on RecentChanges already will have the 'boy who cried wolf' effect for any patroler.
I'm going to regret responding but... Last-modified header indicates that the content of the page has changed, or may have changed. This change could be any type of change, from the trivial, to an entire page change. Equating a change in special:recentchanges with an edit is stupid and wrong. Installing an extension (as an example given above) that could potentially change the format of RC (as some extensions like flaggedRevs to pick a random example do) is a perfectly valid reason to update the modification time. The last modified time is for caching use only. It should not be displayed to the user at all. Any program that does is doing something wrong. >but on low use wikis, a >daily false alarm on RecentChanges already will have the 'boy who cried wolf' >effect for any patroler. Clearly the solution is not to use such a broken program for checking if there are any new edits. It is trivial with the api to actually check if there has been any new edits to the wiki. Its not mediawiki's fault people are reading meaning into an http header that the header is not supposed to carry. (Additionally, considering in the default config we don't even send last-modified headers on special:Recentchanges (more trouble than its worth to figure out if anyone has patrolled any edits), I can't imagine its a very useful program either).
OK http://tools.ietf.org/html/rfc2616#section-14.29 says you can use the time you "believe" you updated it. You don't have to be "sure". And yes MediaWiki very much sends a Last-modified header by default.
By default (going back several versions. Not sure how far) MediaWiki enables RC patrolling. Up until r81544 (which was a couple days ago, so 1.18 which won't be released for several months). If RC patrolling is enabled, no last-modified headers on special:recentchanges.
