404-No-More Project Seeks To Rid the Web of '404 Not Found' Pages 72
First time accepted submitter blottsie (3618811) writes "A new project proposes to do away with dead 404 errors by implementing a new HTML attribute that will help access prior versions of hyperlinked content. With any luck, that means that you'll never have to run into a dead link again. ... The new feature would come in the form of introducing the mset attribute to the <a> element, which would allow users of the code to specify multiple dates and copies of content as an external resource."
The mset attribute would specify a "reference candidate:" either a temporal reference (to ease finding the version cited on e.g. the wayback machine) or the url of a static copy of the linked document.
Lovely Concept, but the true answer (Score:5, Insightful)
As someone who deals with SEO on a daily basis, 404 errors are quite annoying. But there is always a reason to why there is a 404, and a missing/deleted page is not always the reason. This could include a misspelled file name.
Furthermore, linking to expired, cached, or archived versions of a page could be just as problematic as it could have outdated and incorrect information which might infuriate the user even more.
Individual websites should get their 404s under control themselves.
Re:Lovely Concept, but the true answer (Score:5, Interesting)
Also, when it comes to handling all simple 404, there could be a browser extension that would redirect you to archive.org. People would be able to use that on existing content. It's what I'm already doing manually, only this would be faster.
By the way, I always thought that URIs were supposed to handle precisely this - that they were supposed to be unique, universally accessible identifiers for contents and resources - identifiers that, once assigned, wouldn't need to be changed to access the same contents or resources in the future. Oh, hell. Now we have to add extra layers on top of that?
Re: (Score:2)
By the way, I always thought that URIs were supposed to handle precisely this - that they were supposed to be unique, universally accessible identifiers for contents and resources - identifiers that, once assigned, wouldn't need to be changed to access the same contents or resources in the future.
What happens when you want to access something on fubar.com but the domain fubar.com no longer exists?
Re: (Score:3)
Political reasons for URIs to change (Score:5, Interesting)
I always thought that URIs were supposed to handle precisely this - that they were supposed to be unique, universally accessible identifiers for contents and resources - identifiers that, once assigned, wouldn't need to be changed to access the same contents or resources in the future.
That's the intent: cool URIs don't change [w3.org]. But in the real world, URIs disappear for political reasons. One is the change in organizational affiliation of an author. This happens fairly often to documents hosted "for free" on something like Tripod/Geocities, a home ISP's included web space, or a university's web space. Another is the sale of exclusive rights in a work, invention, or name to a third party. A third is the discovery of a third party's exclusive rights in a work, invention, or name that make it no longer possible to continue to offer a work at a given URI.
Re: (Score:2)
Or a site deciding to use a different URI schema because it it better for SEO and not caring about compatibility? That is like 95% of the case for all my 404s.
Re: (Score:2)
Or a site deciding to use a different URI schema because it it better for SEO and not caring about compatibility?
Search engines count inbound links as one of the factors in the rank of a particular document. Keeping old URIs working alongside your new URIs keeps your old inbound links working, which can only improve the placement of the documents on a site. When I moved Phil's Hobby Shop [philshobbyshop.com] to a different shopping cart package, I had the 404 handler try to interpret the old cart's URI schema and route requests to product search.
Re: (Score:1)
Also, when it comes to handling all simple 404, there could be a browser extension that would redirect you to archive.org.....
https://www.google.com/search?... [google.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Also, when it comes to handling all simple 404, there could be a browser extension that would redirect you to archive.org. People would be able to use that on existing content. It's what I'm already doing manually, only this would be faster.
By the way, I always thought that URIs were supposed to handle precisely this - that they were supposed to be unique, universally accessible identifiers for contents and resources - identifiers that, once assigned, wouldn't need to be changed to access the same contents or resources in the future. Oh, hell. Now we have to add extra layers on top of that?
Well, they are. Content does not have to have the same longevity or life-cycle as the URI that once pointed to it, though.
The true answer is yet to come: DHT-FS (Score:5, Interesting)
As user of both Bittorrent and Git and a creator of many "toy" operating systems which have such BT+Git features built in, I would like to inform you that I live in the future that you will someday share, and unfortunately you are wrong. From my vantage I can see that link rot was not ever, and is not now, acceptable. The architects of the Internet knew what they were doing, but the architects of the web were simply not up to the task of leveraging the Internet to its fullest. They were not fools, but they just didn't know then what we know now: Data silos are for dummies. Deduplication of resources is possible if we use info hashes to reference resources instead of URLs. Any number of directories AKA tag trees AKA human readable "hierarchical aliases" can be used for organization, but the data should always be stored and fetched by its unique content ID hash. This even solves hard drive journaling problems, and allows cached content to be pulled from any peer in the DHT having the resource. Such info hash links allows all your devices to always be synchronized. I can look back and see the early pressure pushing towards what the web will one day become -- Just look at ETags! Silly humans, you were so close...
Old resources shouldn't even need to be deleted if a distributed approach is taken. There is no reason to delete things, is there not already a sense that the web never forgets? With decentralized web storage everyone gets free co-location, essentially, and there are no more huge traffic bottlenecks on the way to information silos. Many online games have built-in downloader clients that already rely on decentralization. The latest cute cat video your neighbor notified you of will be pulled in from your neighbor's copy, of if they're offline, then the other peer that they got it from or shared it with, and so on up the DHT cache hierarchy all the way to the source if need be, thus greatly reducing ISP peering traffic. Combining a HMAC with the info hash of a resource allows secured pages to link to unsecured resources without worrying about their content being tampered with: Security that's cache friendly.
<img infohash="SHA-512:B64;2igK...42e==" hmac="SHA-512:SeSsiOn-ToKen, B64;X0o84...aP=="> <-- Look ma, no mixed content warnings! -->
Instead of a file containing data, consider the names merely human readable pointers into a distributed data repository. For dynamism and updates to work, simply update the named link's source data infohash. This way multiple sites can be using the same data with different names (no hot linking exists), and they can point to different points in a resource's timeline. For better deduplication and to facilitate chat / status features some payloads can contain an infohash that it is a delta against. This way, changes to a large document or other resource can be delta compressed - Instead of downloading the whole asset again, users just get a diff and use their cached copy. Periodic "squashing" or "rebasing" of the resource can keep a change set from becoming too lengthy.
Unlike Git and other distributed version controls, each individual asset can belong to multiple disparate histories. Optional per-site directories can have a time component. They can be more than a snapshot of a set of info-hashes mapped to names in a tree: Each name can have multiple info-hashes corresponding to a list of changes in time. Reverting a resource is simply adding a previous hashID to the top of the name's hash list. This way a user can rewind in time, and folks can create and share different views into the Distributed Hash Table File-system. Including a directory resource with a hypertext document can allow users to view the page with the newest assets they have available while newer assets are downloaded. Hypertext documents could then use the file system itself to provide multiple directory views, tagged for different device resolutions, paper vs eink vs screen, light vs dark, etc. CSS provides something similar, but why limit th
Re: (Score:2)
That was an interesting wall of text. I have also dreamed of a distributed replacement for HTTP in order to remove one of the most common reason for the internet being so advertisement-laden: that hosting costs rise in proportion with traffic. Are you or anybody working on implementing this? How much of a latency and disk space overhead would this have? Freenet has similar features, but has enormous overhead (but much of that is to achieve anonymity). How much would it be hampered by current "you're a clien
Re: (Score:2)
Re: (Score:2)
Some people can't get their head around the idea that sometimes no information is far better than obsolete information. And sometimes an absence of information is exactly what you want to know.
And what happens when... (Score:2)
Clippy (Score:2)
Smells like a sneaky way to bring back Clippy: "It looks like the page is missing. Would you like me to run a Bing search for you?"
Re: (Score:3)
I agree.
Just ask - what's more annoying - a "Not Found" message or a redirection to something that the search engine used thought you was asking for. Misspell Goats and you will get Goatse.
Actual Utility? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
So the NSA is to blame for everything ... regardless of how absolutely retarded blaming them is?
Do you realize that your comment makes absolutely no sense in any way?
An asteroid struck the moon ... NSA is to blame!@$!@#%!@#%
Um, 301 and 302 (Score:4, Insightful)
We already have redirects. They work just fine.
Re:Um, 301 and 302 (Score:4, Interesting)
Yes indeed. I took control of a site in 2007 and haven't knowingly broken a link since. Various restructures just led to more redirect entries in .htaccess, and if you somehow have an old 2007 link it should take you to the relevant page on today's site. It just needs disciplined webmasters.
(I'm not the most creative of people and our marketing girls are not exactly the most constructive in dealing with other departments (such as making suggestions for improvement or even opening their mouths and telling me they don't like it in the first place), so they've decided to simply outsource it from under me. The new developers will no doubt break my lovely 7 year chain. But hey ho, that's life.)
Re: (Score:2)
Redirects only work when the hosting party makes them work. Which means they usually don't work.
This proposal is not about the simply a way of expressing what page the source document creator intended you to see. If that version is no longer available from the targeted host (and it may have simply changed) your browser can offer to pull up the expected version from the archive. You can kind of do this manually today. As long as the source page is static, you can generally guess that the date of the targ
Re: (Score:2)
We already have redirects. They work just fine.
Well, they do when they're used. And mostly they aren't. Which is what I have to say to this article: We already have a mechanism for handling this, and yet nobody is actually handling it. What's sad is that CMSes don't handle it for you automatically. Drupal for example has a module which automatically generates path aliases. But there's no module which produces a redirect for the old alias when the path changes.
what a terrible idea (Score:5, Insightful)
Re:what a terrible idea (Score:5, Insightful)
This would also make deletion of content on the web more difficult.
Re: (Score:2)
Not to mention copyright issues, trademark issues, "you are stealing my content" "no we are not" issues.
This is really stupid idea.
404s have a purpose and a place. If Granny Boomer and Missy Millennial can't figure this out, they should stay the fuck off the internet.
Re: (Score:2)
I use ErrorZilla Mod [mozilla.org]. It lets me 'wayback' with one click, and then I get to choose which dates make sense.
I'll keep my 404's, thank you. (Score:4, Insightful)
Basically wouldn't this become a way to hijack requests to drive ad revenue for whoever? :( It Seriously bugs me when Comcast pulls stuff like this -- though perhaps processing this html tag could be something disabled via the browser?
Poor design (Score:4, Insightful)
It seems to me that they are reinventing the <a> element, badly. Semantically, what they are trying to express is a series of related links. What they should be doing is relaxing the restrictions on nested <a> elements and defining the meaning of this, then defining a suitable URN for dated copies of documents. That way they don't need to replicate perfectly fine attributes such as rel in a DSL that isn't used anywhere else and the semantics of the relationship are more accurately described.
Pretty thin on why (Score:4, Insightful)
Re: (Score:2)
Re: (Score:1)
When you use the mset attribute, you would be saying where the content is hosted, yes? What happens when sites like the Wayback Machine [archive.org] cease to exist?
That's obvious -- before it ceases to exist, it should use the mset tag to the Google archive or the Coral cache! That way, when someone points at the archive.org page that no longer exists because the server's offline, they get, er, redirected instead of a 404. Yeah, that's it!
This is a client-side issue, not a server-side issue. You can fix a few 404 issues server-side by practicing good hosting, but it's really down to the client browser to go and find a reasonable facsimile should the original page g
Xanadu (Score:2)
I think it's stuff like this that leads to all (Score:1)
sorts of new security exploits. Do we really need it?
Re: (Score:2)
... and you think this because ? What we really need is for people like you to put just at least an ounce of thought into something before you say it.
There aren't many 404s (Score:3, Insightful)
There aren't many 404s left anyway. Domain dealers are quick to put their hands on every dead link. Which is a shame, because a 404 would be more informative.
Re: (Score:2)
There aren't many 404s left anyway. Domain dealers are quick to put their hands on every dead link. Which is a shame, because a 404 would be more informative.
You don't get a 404 for a non-existent domain. You only get a 404 if you try to go to a non-existent page within a domain that's registered and has a web server running. If the domain's not registered, there's no web server to even return a 404.
Re: (Score:2)
You get a 404 if a domain registrar keeps every expired domain they have and hosts it on their own server, to return you a 404 + ads
I *love* attribute hats! (Score:2)
They go so well with value scarves.
Seriously, 3 typos in the first sentence? "A new project proposes _an_ do away with dead 404 errors by implementing (missing: "a") new HTML attribute _hat_ will help access prior versions of hyperlinked content."
Where are the editors? Oh, right. Carry on.
Re: (Score:2)
what could possibly go wrong.? (Score:2)
Let's have some body add a heartbeat mechanism while we are at it, 'cause you know God forbid we expose a user to technology on something as simple as a computer.
sounds simple enough (Score:2)
all I have to do is update the dead links with new links that wont go to the dead links I never bothered updating in the first place
Possible use by scammers? (Score:1)
Could the tags instead be used for scammy redirect tricks (like "Open"DNS "search results")?
I'd just be happy with... (Score:2)
...a utility that would go through my gazillion saved bookmarks from forever, and see if each still has something of value there. :\
I sometimes in an odd moment sift through the oldest, and easily 8/10 are dead links.
If(!bWebpageExists)...... (Score:1)
{
bHideBehindABrokenUrl = true;
bObtainOutOfDateContent = true;
bProvideContentThatCouldBeUsedToSueUs = true;
bDontBotherDoingYourJob = true;
}
else
{
SomeoneWhoCanDoTheirJob();
}
Honestly, its projects like this, the ones that promote bad practice, which really fu** me off.
Welcome to one of the many pointless projects of 2014, sponsored by
UUIDs as URLs (Score:1)
You know, you could always FIX THE BROKEN LINK! :P
...or just not break it in the first place.
The problem stems from the URL being a machine address necessary to acquire content, but one that is also human-readable which inspires people to treat it as if it were the page's title or something and so they edit it as freely as they edit the page's content.
Just name all of your web pages by UUID. Then, since one random number is just as good as any other, you'll never again have the urge to change your URLs.
Similarly, just use random UUIDs as domain names, and
410 (Score:2)
Sounds like what they're trying to fix is scenarios where the server SHOULD be returning 410, not 404. This has nothing to do with PROPER 404 status codes.
Anyway, is something is so important mirror it yourself and be done with it. No need for html tags. BTW, it seems to blur the line between HTML and HTTP too much.
The Cannibal Internet (Score:2)
And everyone at least knew what a 404 was.
Now we need to eliminate those to monetize things or redirect to a page full of Facebook javascript or other ass-raping javascript to destroy privacy or some page with at least some ads and hopefully 3rd party cookies and a hidden tracker image.
Or something?
We live in the age of the "EVIL INTERNET" --- the interne
But what about the children? (Score:1)
It might take a while to implement (Score:2)