All I know is I get burnt every time e.g., the translation of a built in page name changes, so linking to Rtd> http://en.wikipedia.org/wiki/ --> 200 OK gives little more confidence than linking to Rtd> http://en.wikipedia.org/wiki/Main_Page --> 200 OK Let's see how the real professionals do it $ HEAD -PdS www.google.com HEAD http://www.google.com --> 302 Found HEAD http://www.google.com.tw/ --> 200 OK Oops. Well how about $ HEAD -PSd www.whitehouse.gov HEAD http://www.whitehouse.gov --> 200 OK See. The pros don't tangle one up with kiddie links.

Aryeh Gregor wrote: Isn't this what the new "rel=canonical" facility is designed to cover? I seem to recall we're using that for REDIRECT pages, why not for this kind of situation? -- Phil -- View this message in context: http://www.nabble.com/http%3A--en.wikipedia.org----%3E-301-Moved-Permanentl… Sent from the Wikipedia Developers mailing list archive at Nabble.com.

On Thu, Feb 26, 2009 at 9:10 AM, Phil Boswell <phil.boswell(a)gmail.com> wrote: . . . and to clarify, since I left this out: we *need* redirects to have different URLs, because they actually display slightly different content (the little "redirected from" thing). This reason is not relevant to the proposal at hand.

On Thu, Feb 26, 2009 at 10:42 PM, Angela <beesley(a)gmail.com> wrote: That's not a method I'd seen before. It's quite clever, and it looks like it actually doesn't need JavaScript at all. The basic idea is to set a cookie when sending the 301, and then check for the cookie on the actual page display (and unset it immediately). This would only fail for users with cookies disabled, and those users couldn't log in anyway (perhaps they could edit anonymously, I guess). The cookie could contain both the redirect and the target page names, so it wouldn't add bogus redirect messages if the user loads multiple pages at once. Of course, the Wikia implementation requires JavaScript to be enabled. (Wikia appears to view this as a much smaller cost than MediaWiki developers do.) I don't think that's actually necessary at all, though. Just read the cookie in PHP. It would take considerably more effort to implement this properly in core than the current "canonical" workaround, but it might be worth doing at some point, unless there's a problem I'm missing. . . . anyway, my point was just that the situation in question is different from redirects, which it is, regardless of the above (although the info you give is interesting). On Fri, Feb 27, 2009 at 5:09 AM, Ilmari Karonen <nospam(a)vyznev.net> wrote: Reviewing the definitions, I guess you're right. A 302 with appropriate caching headers seems slightly more appropriate. I don't think it's a big deal, though. On Fri, Feb 27, 2009 at 6:24 AM, Tei <oscar.vives(a)gmail.com> wrote: It's designed to scare you because that type of URL will only work in the majority of cases, not all cases. Try these URLs: http://en.wikipedia.org/w http://en.wikipedia.org/robots.txt Of course, these still work: http://en.wikipedia.org/W http://en.wikipedia.org/Robots.txt And on enwiki, pages starting with lowercase letters happen to be prohibited at the moment. But there'd be no way to access [[wikt:w]] or [[wikt:wiki]] with this kind of URL, for instance, and trying to access [[w:w]] could cause confusion (you have to make sure to uppercase the first letter of the URL). So we use scary/annoying messages to discourage people from using this type of URL with the intent that it actually work in all cases.

On Fri, Feb 27, 2009 at 10:07 AM, Emil Podlaszewski <emil(a)wikia.com> wrote: They do if you just set a cookie and the response has Vary: Cookie. :) I didn't think about the interaction with Squid, but I don't think it would be disastrous. It would have to cache an extra response: the redirect itself (with the cookie-setting header), and then the target page (with the cookie-unsetting header). Both of these would only be cache hits if the requester's cookies matched the original requester's cookies, so nothing incorrect should be served. It does add an extra HTTP request, and therefore an extra roundtrip, so it would slow things down a bit regardless of caching, compared to the current method. But that's true for all HTTP redirects.

On Tue, Feb 24, 2009 at 11:36 AM, Oldak Quill <oldakquill(a)gmail.com> wrote: The Main Page *could* be renamed. Wikipedia *could* also move to www.thebestencyclopediaever.net. 301 isn't an iron-clad guarantee, it's a hint. 302 should be used for things that will definitely or at least plausibly change in the future, not things that hypothetically maybe could change if people really felt like it for some reason, because the latter describes everything on the Internet. In particular, if the target of a 301 redirect moves, that's perfectly fine as long as the previous target redirects to the new target. Which will happen, so what's the problem?

On Fri, Feb 27, 2009 at 11:09 AM, Ilmari Karonen <nospam(a)vyznev.net> wrote: en.wikipedia.org/wiki/Main_Page just looks ugly And If you visit this: en.wikipedia.org./Main_Page It works (with a HTML redirection), but you are amused with a page designed to scare you. It seems work with other words: http://en.wikipedia.org./Cool -- -- ℱin del ℳensaje.

Дана Friday 27 February 2009 22:57:00 jidanni(a)jidanni.org написа: What seems to be the best, but the hardest thing to do is to have the main page served at http://en.wikipedia.org/ and http://en.wikipedia.org/wiki/Main_Page be a 301 redirect to http://en.wikipedia.org/ :)