Last modified: 2012-09-27 01:15:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T23916, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21916 - $wgFeedCacheTimeout client caching issue
$wgFeedCacheTimeout client caching issue
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.14.x
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-21 16:01 UTC by Vitaliy Filippov
Modified: 2012-09-27 01:15 UTC (History)
2 users (show)

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


Attachments
Patch for Wikilog (code similar to MediaWiki's) (3.50 KB, patch)
2009-12-21 16:01 UTC, Vitaliy Filippov
Details

Description Vitaliy Filippov 2009-12-21 16:01:28 UTC
Created attachment 6898 [details]
Patch for Wikilog (code similar to MediaWiki's)

Special:RecentChanges MUST NOT output the Last-Modified header greater than the effective outputted feed modification timestamp.

Suppose the following situation:
0. RSS reader ("client") updates some recentchanges feed.
1. Wiki caches OLD version of feed with OLD timestamp
2. So client caches OLD version of feed with OLD timestamp
3. Some new change is added to the feed - now it has NEW update timestamp
4. It happens that client updates feed BEFORE $wgFeedCacheTimeout seconds passed after the first update
5. So Wiki outputs OLD version of feed with NEW (!!!) timestamp
6. Client caches OLD version of feed with NEW timestamp
7. In the future, client sends requests with If-Modified-Since = NEW timestamp
8. So Wiki outputs 304 Not Modified
9. So client does not get the new version of feed! (client thinks it already has the newest version)

This buggy behaviour was copied into Wikilog extension by its author, and this bug was found there at first :-) it isn't so important in RecentChanges feed because it usually contains more items, and RecentChanges don't need such freshness.

Wikilog author wants to hear your opinion about this bug before committing a fix for this bug into his repository.

The fix is getting effective feed modification timestamp from cache and outputting it as Last-Modified header instead of getting modification timestamp of the actual data.

The patch for Wikilog is attached, it's code is very similar (copy-paste), but in MediaWiki it's dispersed into includes/ChangesFeed.php and includes/specials/SpecialRecentchanges.php, so it'll be slightly harder to create an equal fix.
Comment 1 Alexandre Emsenhuber [IAlex] 2010-04-05 16:16:45 UTC
Fixed MediaWiki in r64621. If you also want to fix the extension, please open another bug in MediaWiki extensions/Wikilog.
Comment 2 Juliano F. Ravasi 2010-06-25 04:15:53 UTC
Fix ported to Wikilog in r68551.
Comment 3 Juliano F. Ravasi 2010-06-25 04:17:50 UTC
Sorry, errata. Wrong revision number.
Fix ported to Wikilog in r68553.

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


Navigation
Links