Hello, say, when we are running our link checker programs and see HEAD http://en.wikipedia.org/ --> 301 Moved Permanently HEAD http://en.wikipedia.org/wiki/Main_Page --> 200 OK HEAD http://wikimania2007.wikimedia.org/ --> 301 Moved Permanently HEAD http://wikimania2007.wikimedia.org/wiki/Main_Page --> 200 OK HEAD http://radioscanningtw.jidanni.org/ --> 301 Moved Permanently HEAD http://radioscanningtw.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK HEAD http://taizhongbus.jidanni.org/ --> 301 Moved Permanently HEAD http://taizhongbus.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK HEAD http://transgender-taiwan.org/ --> 301 Moved Permanently HEAD http://transgender-taiwan.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK does that mean we should hardwire those extra long paths into our web pages instead of the less worrisome versions we are using now?
I mean when I see a 301, I update my webpages, but momma said stay out of alleys...
Maybe we could make /wiki/ show the front page and not just redirect? Then we would have:
http://en.wikipedia.org/wiki/ --> 200 OK http://en.wikipedia.org/wiki/Main_Page --> 200 OK
http://radioscanningtw.jidanni.org/ --> 200 OK http://radioscanningtw.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK
http://taizhongbus.jidanni.org/ --> 200 OK http://taizhongbus.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK
There's something to be said for making the URLs shorter and prettier, although I also understand the desire to minimize duplication. Thoughts?
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.
On Mon, Feb 23, 2009 at 11:19 PM, Remember the dot rememberthedot@gmail.com wrote:
Maybe we could make /wiki/ show the front page and not just redirect?
Then we have duplicate URLs for the same content. I don't see any problem with keeping the 301.
On Tue, Feb 24, 2009 at 12:02 AM, jidanni@jidanni.org wrote:
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
If the main page name changes, you can expect a redirect to be put in place from the old name.
Aryeh Gregor wrote:
On Mon, Feb 23, 2009 at 11:19 PM, Remember the dot rememberthedot@gmail.com wrote:
Maybe we could make /wiki/ show the front page and not just redirect?
Then we have duplicate URLs for the same content. I don't see any problem with keeping the 301.
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?
On Thu, Feb 26, 2009 at 9:10 AM, Phil Boswell phil.boswell@gmail.com 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?
Matt Cutts of Google has stressed that rel="canonical" should only be used where redirects aren't feasible:
http://googlewebmastercentral.blogspot.com/2009/02/canonical-link-element-pr... Slide 8: "* Far better to avoid dupes and normalize urls in the first place * If you're a power user, exhaust alternatives first"
Besides, duplicate URLs are just kind of icky. It seems nicer on the basis of general web principles to have a single URL where possible, unless there are specific good reasons not to.
On Thu, Feb 26, 2009 at 9:10 AM, Phil Boswell phil.boswell@gmail.com wrote:
I seem to recall we're using that for REDIRECT pages, why not for this kind of situation?
. . . 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 Fri, Feb 27, 2009 at 2:43 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Thu, Feb 26, 2009 at 9:10 AM, Phil Boswell phil.boswell@gmail.com wrote:
I seem to recall we're using that for REDIRECT pages, why not for this kind of situation?
. . . 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.
No, it's possible to add "redirected from" but still change the URL. Wikia did this before the canonical tag came in.
The code is here: https://svn.wikia-code.com/wikia/trunk/extensions/wikia/HardRedirectsWithJSText/HardRedirectsWithJSText.php
Angela
On Thu, Feb 26, 2009 at 10:42 PM, Angela beesley@gmail.com wrote:
No, it's possible to add "redirected from" but still change the URL. Wikia did this before the canonical tag came in.
The code is here: https://svn.wikia-code.com/wikia/trunk/extensions/wikia/HardRedirectsWithJSText/HardRedirectsWithJSText.php
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@vyznev.net wrote:
The actual semantic difference between 301 and 302, as Oldak notes, is that clients that can choose which URL to use in the future should prefer the redirect target for 301, whereas they should keep using the original URL for 302.
(There's also some differences with cacheability by default, but explicit expiry and cache control headers override those.)
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@gmail.com wrote:
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
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.
2009/2/27 Aryeh Gregor Simetrical+wikilist@gmail.com: [...]
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.
[...]
Not all requests hit the backend if you have squid or varnish in front of your apaches.
Emil
On Fri, Feb 27, 2009 at 10:07 AM, Emil Podlaszewski emil@wikia.com wrote:
Not all requests hit the backend if you have squid or varnish in front of your apaches.
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.
It also completely screws up the redirected from line if you CTRL+Click on a number of redirects. ie: When trying to mass delete redirects tagged for deletion.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] -Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com) -MonkeyScript (http://monkeyscript.org) -Animepedia (http://anime.wikia.com) -Narutopedia (http://naruto.wikia.com) -Soul Eater Wiki (http://souleater.wikia.com)
Aryeh Gregor wrote:
On Fri, Feb 27, 2009 at 10:07 AM, Emil Podlaszewski emil@wikia.com wrote:
Not all requests hit the backend if you have squid or varnish in front of your apaches.
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.
2009/2/24 jidanni@jidanni.org:
Hello, say, when we are running our link checker programs and see HEAD http://en.wikipedia.org/ --> 301 Moved Permanently HEAD http://en.wikipedia.org/wiki/Main_Page --> 200 OK HEAD http://wikimania2007.wikimedia.org/ --> 301 Moved Permanently HEAD http://wikimania2007.wikimedia.org/wiki/Main_Page --> 200 OK HEAD http://radioscanningtw.jidanni.org/ --> 301 Moved Permanently HEAD http://radioscanningtw.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK HEAD http://taizhongbus.jidanni.org/ --> 301 Moved Permanently HEAD http://taizhongbus.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK HEAD http://transgender-taiwan.org/ --> 301 Moved Permanently HEAD http://transgender-taiwan.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK does that mean we should hardwire those extra long paths into our web pages instead of the less worrisome versions we are using now?
I mean when I see a 301, I update my webpages, but momma said stay out of alleys...
Unfortunately I don't think HTTP has a status code for "move permanently but this redirect will always be here". 301 is probably the best option out of what there is.
2009/2/24 Thomas Dalton thomas.dalton@gmail.com:
2009/2/24 jidanni@jidanni.org:
Hello, say, when we are running our link checker programs and see HEAD http://en.wikipedia.org/ --> 301 Moved Permanently HEAD http://en.wikipedia.org/wiki/Main_Page --> 200 OK HEAD http://wikimania2007.wikimedia.org/ --> 301 Moved Permanently HEAD http://wikimania2007.wikimedia.org/wiki/Main_Page --> 200 OK HEAD http://radioscanningtw.jidanni.org/ --> 301 Moved Permanently HEAD http://radioscanningtw.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK HEAD http://taizhongbus.jidanni.org/ --> 301 Moved Permanently HEAD http://taizhongbus.jidanni.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK HEAD http://transgender-taiwan.org/ --> 301 Moved Permanently HEAD http://transgender-taiwan.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK does that mean we should hardwire those extra long paths into our web pages instead of the less worrisome versions we are using now?
I mean when I see a 301, I update my webpages, but momma said stay out of alleys...
Unfortunately I don't think HTTP has a status code for "move permanently but this redirect will always be here". 301 is probably the best option out of what there is.
Might not 302 be better in that it indicates the redirect will always be there, though the target might move in the future? Where 301 suggests that the client "ought to automatically re-link references", 302 suggests "client SHOULD continue to use the Request-URI for future request".
Although 302 indicates temporary move and 301 indicates permanent move, since the Main_page could be renamed, 302 might be more fitting anyway...
On Tue, Feb 24, 2009 at 11:36 AM, Oldak Quill oldakquill@gmail.com wrote:
Might not 302 be better in that it indicates the redirect will always be there, though the target might move in the future? Where 301 suggests that the client "ought to automatically re-link references", 302 suggests "client SHOULD continue to use the Request-URI for future request".
Although 302 indicates temporary move and 301 indicates permanent move, since the Main_page could be renamed, 302 might be more fitting anyway...
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?
Aryeh Gregor wrote:
On Tue, Feb 24, 2009 at 11:36 AM, Oldak Quill oldakquill@gmail.com wrote:
Might not 302 be better in that it indicates the redirect will always be there, though the target might move in the future? Where 301 suggests that the client "ought to automatically re-link references", 302 suggests "client SHOULD continue to use the Request-URI for future request".
Although 302 indicates temporary move and 301 indicates permanent move, since the Main_page could be renamed, 302 might be more fitting anyway...
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.
The actual semantic difference between 301 and 302, as Oldak notes, is that clients that can choose which URL to use in the future should prefer the redirect target for 301, whereas they should keep using the original URL for 302.
(There's also some differences with cacheability by default, but explicit expiry and cache control headers override those.)
Since http://en.wikipedia.org/ is arguably a better URL for linking to the English Wikipedia main page than http://en.wikipedia.org/wiki/Main_Page, I'd see no reason not to make the redirect a 302. We'd just be telling visitors that "our main page is over there, but feel free to keep using this shorter URL".
On Fri, Feb 27, 2009 at 11:09 AM, Ilmari Karonen nospam@vyznev.net wrote:
Aryeh Gregor wrote:
On Tue, Feb 24, 2009 at 11:36 AM, Oldak Quill oldakquill@gmail.com wrote:
Might not 302 be better in that it indicates the redirect will always be there, though the target might move in the future? Where 301 suggests that the client "ought to automatically re-link references", 302 suggests "client SHOULD continue to use the Request-URI for future request".
Although 302 indicates temporary move and 301 indicates permanent move, since the Main_page could be renamed, 302 might be more fitting anyway...
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.
The actual semantic difference between 301 and 302, as Oldak notes, is that clients that can choose which URL to use in the future should prefer the redirect target for 301, whereas they should keep using the original URL for 302.
(There's also some differences with cacheability by default, but explicit expiry and cache control headers override those.)
Since http://en.wikipedia.org/ is arguably a better URL for linking to the English Wikipedia main page than http://en.wikipedia.org/wiki/Main_Page, I'd see no reason not to make the redirect a 302. We'd just be telling visitors that "our main page is over there, but feel free to keep using this shorter URL".
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
Since http://en.wikipedia.org/ is arguably a better URL for linking to the English Wikipedia main page than http://en.wikipedia.org/wiki/Main_Page, I'd see no reason not to make the redirect a 302. We'd just be telling visitors that "our main page is over there, but feel free to keep using this shorter URL".
Right on! (1960's language)
T> http://en.wikipedia.org/wiki/Main_Page just looks ugly
And don't forget those of us who prefer to configure our sites with genuine index.php URLs.
$ HEAD -dSP http://transgender-taiwan.org/ HEAD http://transgender-taiwan.org/ --> 301 Moved Permanently HEAD http://transgender-taiwan.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK
What this says is that all webmasters who link to the former tidy URL, should instead change that to the latter blathersome URL. Fat chance they would say, especially if the were the Dmoz indexers, etc. "Come back when your site is fixed".
Дана Friday 27 February 2009 22:57:00 jidanni@jidanni.org написа:
Since http://en.wikipedia.org/ is arguably a better URL for linking to the English Wikipedia main page than http://en.wikipedia.org/wiki/Main_Page, I'd see no reason not to make the redirect a 302. We'd just be telling visitors that "our main page is over there, but feel free to keep using this shorter URL".
And don't forget those of us who prefer to configure our sites with genuine index.php URLs.
$ HEAD -dSP http://transgender-taiwan.org/ HEAD http://transgender-taiwan.org/ --> 301 Moved Permanently HEAD http://transgender-taiwan.org/index.php?title=%E9%A6%96%E9%A0%81 --> 200 OK
What this says is that all webmasters who link to the former tidy URL, should instead change that to the latter blathersome URL. Fat chance they would say, especially if the were the Dmoz indexers, etc. "Come back when your site is fixed".
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/ :)
wikitech-l@lists.wikimedia.org