On Stack Exchange, as with any web site containing external links, there's a problem known as link rot. This is the phenomenon whereby some URLs no longer point to the information that they once pointed to. Sometimes, the domain has been disconnected. Perhaps it's under new ownership, and the original deep links no longer work. Or, frequently, the website is reorganized and content is in a new location.
To deal with this problem, the team is currently working on a soon-to-be-revealed /review/broken-links
tool, and errors are issued at post submission time:
That's a nice idea, but the implementation is flawed. In the attempt to deal with this problem, another is being created: You can no longer post links to sites which are not valid as imagined by the author of the broken link detector without the post showing up in /review
and/or getting the above error.
There are several cases when 'broken' links are currently disallowed but they should be allowed:
http://localhost
and friends. Usually, this is not an issue wherein someone is attempting to link to attempts to link to a public site like http://localhosting.com/ but accidentally types this invalid domain. It's usually (based on the first 10 links in/review
) an attempt to link to a local domain for debugging or modifying a server running at that location. Sure, it won't work for the average Internet user (or the link validator bot), but these links should work for someone trying to reproduce the problem described in a question or follow along with an answer.As described in Are IP address links valid in posts?, "the vast majority of these links are broken and/or link nowhere." Note that this implies that there's a minority which are intentional. Perhaps someone was attempting to write
Now that you've flashed dd-wrt to your router, navigate to
192.168.1.1
by clicking on that IP address and you should see the web GUI where you can...or
I've written a patch for the omnibar logic for Chromium to allow arithmetic calculations to be performed, but when I click on an IP address like
74.125.224.240
which should direct you to the google.com homepage, some users report that it tries to compute something instead. Apply the patch from here on Github, does it work for you? If not, what is your configuration (extensions/userscripts etc) and why doesn't the patch work?Posts like these should be allowed to link to IPs, and not have to wrap them in code backticks or blocks. Of course, it's impossible to determine algorithmically whether this is the case, so the post should go through with a warning like:
Oops! You're linking to the IP address blah.blah.blah.blah. These links break quickly and may not work in the future.
[ Whoops, please fetch the host name for this IP and fix my post ]
[ No, I meant to link to an IP address ]The link validator checks for redirects, and reports a broken link if a redirect is detected. As described at this Webmasters question, the vaildator assumes that 301 and 302 redirects won't work indefinitely and should always be changed to the new address. (By the way, wouldn't it be nice if the
/review
tool could fetch the destination page and suggest an edit?). I have no objection to this for many links. However, some links will always contain a redirect: Consider http://example.com, which redirects to http://www.iana.org/domains/example/ and probably can be assumed to do so for the forseeable future. A link to a page intended to demonstrate redirection should occasionally be allowed. Similarly, a link to a page intended to demonstrate a 404 should be allowed, though a warning should be issued.- There are probably other use cases for links which don't report
200 OK
to the link validator script. I can't guess at all of them, and neither can any other developer.
I do want to see fewer broken links on the network. I agree that the current tools will catch many broken outbound links that should be changed. However, I take issue with the fact that the current implementation handles any non-conforming links as impassable errors. They should be warnings, and the warnings should be dismissable.