Last modified: 2005-05-14 06:12:06 UTC
BUG MIGRATED FROM SOURCEFORGE http://sourceforge.net/tracker/index.php?func=detail&aid=1007164&group_id=34373&atid=411192 Originally submitted by Finlay McWalter (wfmcwalter) 2004-08-11 12:44 There have been several reports on en.wikipedia of anon users complaining they've received the "you have new messages" indicator (even though their talk page is non-existent). When they click the link in the indicator they're sent to the talk page of some entirely different anon. For example, [[User 132.205.47.183]] is being repeatedly sent to [[User talk:195.93.34.7]] This may be happening quite a lot (I suspect lots of anons ignore it due to confusion, or just leave in the huff). Contacts: * User:RickK * User:Ilyanep ------------------------- Additional comments ------------------------ Date: 2004-08-14 08:09 Sender: SF user timwi This bug has been migrated to MediaZilla: http://bugzilla.wikipedia.org/show_bug.cgi?id=25 Please leave additional comments or attachments there.
This can be a terrible annoyance. I edited for a little bit as an anon the other day while on a machine using AOL, and continually got "you have new messages" alerts, which inevitably were of the form "please stop vandalizing WP" or "Thanks for your test. It worked and has been removed. Please read the editing guidelines..." It felt as though the entire system were broken, and made it uncomfortable to edit. Upgrading severity to critical; affects a significant portion of users in a very visible and frustrating way (cf. the many anon talk pages recently full of "I'm not vandalizing!" "This isn't my IP!" "What edits are you talking about?").
This is not a "critical" bug because it does not impair the use of the MediaWiki system for anyone. Allow me instead to set the priority to "high".
I've been noticing this regularly for the last month or so. In that time, the IP I post with is always recorded correctly by Wikipedia. But I regularly get new message notifications for random IP addresses. In those threads there are invariably a lot of confused anon users shocked they've been accused of vandalism they did not do. This is not a proxy server issue - as I said the IP address detected by Wikipedia is correct and never changes. In some of the threads, users post that they're in internet cafes in Europe, or they're AOL users in America. I'm a DSL user in Seoul, Korea. I find it highly unlikey we'd be sharing common proxy servers to access Wikipedia. I agree this is a critical problem because some of the accusations that a new user might receive would be enough to scare them away from Wikipedia completely.
If they're unrelated IP addresses, the most likely problem is that pages with new message notifications are being cached by the squids at our end, and then get served out to other users. That's not supposed to happen, though...
(In reply to comment #4) > If they're unrelated IP addresses, the most likely problem is that pages with new message notifications are being cached by the squids at our > end, and then get served out to other users. That's not supposed to happen, though... I just got a New Message notification for http://en.wikipedia.org/wiki/User_talk:198.81.26.73 . When I went to that talk page, the only message in that user talk page was a "{{test}}" created 22 Jul 2004 (UTC). That's over a month ago, so it seems unlikley that Squid would have a page cached from that long ago.
Jack, which page was having the new talk notification? There is a possibility to have pages in cache for one month, I'd like to check the store logs.
(In reply to comment #5) > I just got a New Message notification for http://en.wikipedia.org/wiki/User_talk:198.81.26.73 . When > I went to that talk page, the only message in that user talk page was a "{{test}}" created 22 Jul > 2004 (UTC). That's over a month ago, so it seems unlikley that Squid would have a page cached from > that long ago. That's an AOL web proxy, with plenty of hits logged in just the last few hours. It doesn't matter how long ago the talk page was edited; if the flag was never cleared it will continue to show up in hits by that IP. Do you see the notification only on certain pages, or does it appear consistently?
(In reply to comment #7) > That's an AOL web proxy, with plenty of hits logged in just the last few hours. It doesn't matter how long ago > the talk page was edited; if the flag was never cleared it will continue to show up in hits by that IP. > Do you see the notification only on certain pages, or does it appear consistently? Sometimes I see it on the Main Page but more often than not it appears randomly when I'm surfing between articles. I believe that if I ignore it, the next article I surf to will also display the New Messages notification. I'll check next time and post back here.
(In reply to comment #6) > Jack, which page was having the new talk notification? There is a possibility to > have pages in cache for one month, I'd like to check the store logs. I believe I saw it on either the article http://en.wikipedia.org/wiki/Astroturfing or http://en.wikipedia.org/wiki/Grassroots_democracy . Sorry, not 100% sure. I'll pay more attention next time and post exactly where I see it.
OK, I have some more information. Just now I was clicking "Random Page" and came upon http://en.wikipedia.org/wiki/Malcolm_X_%28movie%29 which had a link to the http://en.wikipedia.org/wiki/User_talk:195.93.33.9 user talk page. I browsed to another page (clicking) "Denzel Washington" and the new message notification disappeared. Returning to Malcolm X (movie) via a search and the notification was there again, and the same after a Refresh and shift-Refresh. I loaded the same page in IE on a different computer connected to my same local NAT router, and the notification also appeared. Although I guess it's possible that this is caused by the page being cached at /my/ ISP. I then tried with Mozilla on both machines (I use IE by default) and the notification was not there. Hope this helps.
It appear to happen in search engine archives like in the french part of google http://www.google.fr/search?q=cache:8N4LeppMuCcJ:fr.wikipedia.org/wiki/Accueil+wikipedia&hl=fr and google got contributions http://fr.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=206.162.138.4
Right, to see this problem try searching google for: site:en.wikipedia.org "you have new messages" http://www.google.com/search?q=site:en.wikipedia.org+% 22you+have+new+messages%22 Then view Google's cache of some of the pages. The user pages the new message notification links to contain requests not to vandalize, etc. That googlebot's vandalizing Wikipedia again :-)
Hi, Just now I got the New Message alert for 64.12.117.10 (not my IP) on http://en.wikipedia.org/wiki/Main_Page ! Surely this bug is serious enough to warrant some more attention? A quick google search for '"You have new messages" site:en.wikipedia.org' and then viewing the cached pages will show you that anons regularly see New Message alerts for a whole bunch of incorrect IPs.
Applied some fix for this. The number of "new messages" headers sent to anons should now start reducing. As long as there are still cached pages having this header, it will not become zero. I'll probably purge the caches during low-traffic times at the weekend.
(In reply to comment #14) > Applied some fix for this. The number of "new messages" headers sent to anons > should now start reducing. As long as there are still cached pages having this > header, it will not become zero. > I'll probably purge the caches during low-traffic times at the weekend. Hi, I'm not sure the fix is working: just now I got another New Messages notification for User_talk:64.12.117.10 on http://en.wikipedia.org/wiki/Main_Page . That User Talk page was updated yesterday (or today depending on your time zone) so it seems pages with the header are still being cached.
*** Bug 842 has been marked as a duplicate of this bug. ***
This bug appears to have returned. Seen it several times in the last few days, including on Main_Page.
I think I've got this cleared up; JeLuF's earlier fix was being blocked because the cache headers were already sent by the time this code is executed. I've now got it buffering output, and sending the cache headers after the skin code runs so it has a chance to declare the page uncacheable. There may still be broken pages in the squid caches, so run a purge and test if possible if you find any more in the short term.
*** Bug 334 has been marked as a duplicate of this bug. ***
