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.

Version: 1.14.x
Severity: minor

Attached: