Anthere wrote: We could really use more details here, such as *what sort* of wrong dates are seen. Specifically what they are, and specifically where they are seen. Comparitive times (eg 'I saw "May 99, 2199" at the date for three changes on Recent Changes at about 12:40 UTC on May 16') and confirming screen shots may help. If it's an old cached page, vs it's the specific year 2025 thing, vs it's a year 2003 thing, etc might have to be treated differently. This sort of thing is generally due to lagging in the database replication, and is more prone when load is heavy (and especially when painful page rename operations and such are going on). Cache updates might not be going through properly. -- brion vibber (brion @ pobox.com)

On 5/18/05, Brion Vibber <brion(a)pobox.com> wrote: Take a look at the backwards history of [[en:User:Maustrauser]], where the timestamps actually run backward. Also there's [[en:Mineirão]]. Here an anon created the article and made several subsequent edits. Then user Jp347 added the copyedit tag - but the database records that copyedit request as the *first* edit. Commending on WP:HD, Jp347 says the timestamp attached to the copyedit addition isn't correct, and that rather than create the article as the history suggests, he added the tag afterward, as described above. I've seen weird stuff happen before, where some edits are /temporarily/ hidden (e.g. where users appear to be editwarring with themselves) and I guess this is due to the database lag Brion mentioned. That problem always went away after a while (presumably after the slaves caught up) but this problem seems to be a genuinely (and permanently) wrong database condition. So I guess this is a different issue, presumably something to do with timestamps. -- John Fader

Hi, I've installed the MediaWiki code on my site MediaWiki <http://wikipedia.sf.net/> (/http://wikipedia.sf.net//): 1.4.0 PHP <http://www.php.net/> (/http://www.php.net//): 4.3.11 (cgi-fcgi) MySQL <http://www.mysql.com/> (/http://www.mysql.com//): 4.0.24-standard and I've got a problem with firefox(IE doesn't have it): Pages which can be edited are displayed only the first time I visit them, next visits return a blank page (only html and body tags). This can be observed on http://driversplanet.com/wiki/index.php?title=Epson/EPSON_Stylus_COLOR_600_… I've tried to add &action=purge to the URL which works, but setting $wgEnableParserCache = false; in LocalSettings.php changes nothing. The only change between the working page and the blank page headers is "If-Modified-Since: Tue, 17 May 2005 13:37:41 GMT" in the blank page header. I don't have access to php.ini so I can't offer any php logs :/ Enabling the wgDebugLogFile returned the following differences: ------------------------------------------------------------------------ bad page: GET User::loadFromSession() unable to load from memcached Using reader #0: IP User::loadFromSession() successfully saved user User:spreadBlock() Block::load: '', '1', 1 -- client send If-Modified-Since: Thu, 19 May 2005 11:08:36 GMT -- we might send Last-Modified : Thu, 19 May 2005 11:08:36 GMT ** private caching; Thu, 19 May 2005 11:08:36 GMT ** CACHED client: 20050519110836 ; user: 20050519105736 ; page: 20050519110836 Request ended normally ------------------------------------------------------------------------ good page (after deleting the sess_* file which never gets deleted by itself) GET User::loadFromSession() unable to load from memcached Using reader #0: IP User::loadFromSession() successfully saved user User:spreadBlock() Block::load: '', '1', 1 -- client send If-Modified-Since: Thu, 19 May 2005 11:08:36 GMT -- we might send Last-Modified : Thu, 19 May 2005 11:19:38 GMT READY client: 20050519110836 ; user: 20050519105736 ; page: 20050519111938 tryFileCache() - not cacheable ** private caching; Thu, 19 May 2005 11:19:38 GMT ** Request ended normally ------------------------------------------------------------------------ I will be grateful for your help. -- Jure Špik, Carpe diem, d.o.o., Kranj

http://meta.wikimedia.org/wiki/User_talk%3AAnthere#A_Desperate_Call_for_Help Some screenshots are displayed here about the bug. Seems really like cache no ? Anthere Anthere a écrit:

Zigger wrote: MediaWiki <http://wikipedia.sf.net/> 1.4.4 shows a slight change in headers but the same behavior working header is HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 23 May 2005 09:39:28 GMT X-Powered-By: ASP.NET, PHP/4.3.11 Connection: close Content-Type: text/html; charset=utf-8 Content-Language: en Vary: Accept-Encoding, Cookie, Accept-Encoding Expires: -1 Cache-Control: private, must-revalidate, max-age=0 Last-Modified: Thu, 19 May 2005 10:57:36 GMT Content-Encoding: gzip while header for blank page is HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 23 May 2005 09:40:00 GMT X-Powered-By: ASP.NET, PHP/4.3.11 Connection: close HTTP/1.0: 304 Not Modified Content-Type: text/html Vary: Accept-Encoding, Cookie, Accept-Encoding Expires: -1 Cache-Control: private, must-revalidate, max-age=0 Last-Modified: Thu, 19 May 2005 10:57:36 GMT Content-Encoding: gzip (for the non working page there are also these request headers: If-Modified-Since: Thu, 19 May 2005 10:57:36 GMT Cache-Control: max-age=0) Could this be a browser bug and if the page returns 304 in the header firefox should reload it internally ? Jure

Zigger wrote: Sorry, I don't think the headers are double. In my previous posts I just posted the differences between the working headers and the non-working headers. The HTTP response now changed to HTTP/1.1: 304 Not Modified but the page still won't load. I just found out, that if I do a "hard refresh" with ctrl+f5 browser reloads the page ok. Thank you for your help. Do you think this would be better discussed between us privately as noone on the list seems to have anything to add ? Jure -- Ecosystem failing. Need ride off this rock. Pick up at Long 14e3365, Lat 46n2425 , Earth.