Last modified: 2011-02-07 02:52:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27140 - Add information to $wgInvalidateCacheOnLocalSettingsChange for low-traffic wiki warning
Add information to $wgInvalidateCacheOnLocalSettingsChange for low-traffic wi...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Documentation (Other open bugs)
1.18.x
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-03 17:47 UTC by Dan Jacobson
Modified: 2011-02-07 02:52 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2011-02-03 17:47:03 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.
Comment 1 Bawolff (Brian Wolff) 2011-02-03 20:34:17 UTC
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.
Comment 2 Dan Jacobson 2011-02-04 03:40:01 UTC
I see, I need to adapt my LocalSettings.php to the new stuff in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/77878 .
Comment 3 Dan Jacobson 2011-02-04 11:12:59 UTC
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;
Comment 4 Bawolff (Brian Wolff) 2011-02-04 17:36:08 UTC
/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.
Comment 5 Chad H. 2011-02-04 17:41:38 UTC
No, we're not adding that comment.
Comment 6 Dan Jacobson 2011-02-05 01:56:36 UTC
(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.
Comment 7 LordAndrew 2011-02-05 06:07:13 UTC
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.
Comment 8 Dan Jacobson 2011-02-05 08:08:14 UTC
(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.
Comment 9 LordAndrew 2011-02-05 16:49:57 UTC
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.
Comment 10 Dan Jacobson 2011-02-06 02:18:36 UTC
(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.
Comment 11 Bawolff (Brian Wolff) 2011-02-07 01:58:20 UTC
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).
Comment 12 Dan Jacobson 2011-02-07 02:39:16 UTC
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.
Comment 13 Bawolff (Brian Wolff) 2011-02-07 02:52:19 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links