Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

404-No-More Project Seeks To Rid the Web of '404 Not Found' Pages

Unknown Lamer posted about 6 months ago | from the rm-is-not-forever dept.

The Internet 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.

cancel ×

72 comments

Sorry! There are no comments related to the filter you selected.

Lovely Concept, but the true answer (5, Insightful)

Anonymous Coward | about 6 months ago | (#46810523)

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 (4, Interesting)

K. S. Kyosuke (729550) | about 6 months ago | (#46810653)

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:Lovely Concept, but the true answer (1)

rudy_wayne (414635) | about 6 months ago | (#46810691)

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:Lovely Concept, but the true answer (-1)

Anonymous Coward | about 6 months ago | (#46810705)

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?

That's when you grab your ankles and kiss your stinky asshole goodbye!

Re:Lovely Concept, but the true answer (2)

K. S. Kyosuke (729550) | about 6 months ago | (#46810989)

Well, I guess all measures work only to a certain extent. You could equally ask if a paid data backup service covers the case of a 10km asteroid obliterating all life on Earth, or a nuclear war. But that doesn't mean that botching it by not adopting reasonably workable measures is justified by these extreme examples.

Political reasons for URIs to change (4, Interesting)

tepples (727027) | about 6 months ago | (#46810723)

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:Political reasons for URIs to change (1)

rioki (1328185) | about 6 months ago | (#46821325)

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:Political reasons for URIs to change (1)

tepples (727027) | about 6 months ago | (#46822065)

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:Lovely Concept, but the true answer (1)

Em Adespoton (792954) | about 6 months ago | (#46811025)

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:Lovely Concept, but the true answer (1)

jrumney (197329) | about 6 months ago | (#46811083)

Years ago, I was using a Firefox extension that did this automatically. I don't know if that extension still exists, as I don't use Firefox any more. URLs are not URIs though - L is for Locator, they are supposed to point to a specific location, not be a unique identifier independent of location.

Re:Lovely Concept, but the true answer (1)

luis_a_espinal (1810296) | about 6 months ago | (#46814201)

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 (5, Interesting)

VortexCortex (1117377) | about 6 months ago | (#46812169)

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 the feature to styles and images when it can be applied more generally to all content and their histories as well. Separate Form from Function; Separate Content from Presentation; Separate Trust from Provider; Separate Names from Locations; Separate Software from Instructions; Separate Space from Time... I mean, duh, right?

Data silos have always beet at odds with the Internet's inherently decentralized nature. This peer to peer architecture is its greatest strength, and why it can withstand censorship or thermonuclear war. The Internet can route data around cities in seconds if they disappear from its mesh. There is no such thing as a client or server at the IP level, everyone is a peer. The stupid centralized hierarchical approach is full of bottlenecks, DOS vulnerability, and despotic spying. Getting your data from the nearest peer prevents upstream sources from tracking your browsing habits -- They don't need to track us, TV and print ads never did.

The biggest elephant in the room is silly pre-internet OS design that doesn't work with our multi-device lives. This will end soon too. The virtual machine OS and it's cross platform applications will rule all hardware soon. People use hardware for the programs, not the OS. Instruction-sets are irrelevant, resistance is feudal, you will be ASCII-eliminated. Synchronizing and updating your data and upgrading your OS should NOT be a problem in this day and age. A distributed file system and cross platform OS can handle all of that for you. New OS image? It's just another file. The VM Operating Systems will compile the bytecode once at code-install and leverage both cross platform applications and native speeds, without additional program startup overhead. All you have to do is write a real OS instead of a dumb Kernel -- Protip: If your Kernel doesn't have a program bytecode compiler, you're doing it wrong. This will happen soon, I have forseen it: That is how my "toy" operating systems work, it is how Google's NACL Apps work, it would be a simple addition to Android. For a fast and dirty approach I could easily upgrade BSD's Unix kernel with LLVM's bytecode compiler. You should never distribute programs as binaries, only cross platform intermediary output. This enables per program selective library linking: Dynamic or Static. It's such a braindead obvious feature, that if POSIX wasn't design by committee cluster fuck, you'd have assemble on install bytecode formats as a replacement for ELF long ago.

I use a system similar to PGP fingerprinting for the update signatures and community trust graphs. Seed boxes can specify how much of a resource to save for backup / re-seeding. Families don't have to go through creepy 3rd parties like Facebook or G+ to share pictures, videos and comments with your friends and relatives. What if a device dies? Nothing of value is lost. We Separate File Names from Storage Locations, remember? The DHT-FS is built for redundancy. I can set how much or less redundancy I want for any view -- I have a backup view that I add resources and directory trees to so that even if I delete all other references, the data remains. All of your files, pictures, etc. should always be automatically backed up amongst your friends and families for as long as you live. Backups of images and videos happen immediately quite naturally primarily because all the grandparents go and view them all as soon as the "Summer Vacation 2014 [19 new]" appears in their notifications. RAID-G is amazingly fast, it has nothing better to do!

Folks can have a directory with private encrypted files. The normal remote view is just a directory named like "Joe Sixpack's data [private]", which stores a set of infohashes and files full of encrypted noise and an encrypted directory view. "Joe, I'm so sorry about the house fire. Come over any time if you need to use your private data before it's finished re-syncing." Joe gives his password to unlock the encrypted directory view and all the data is there, safe and backed up just like everyone else's data at everyone else's homes. PGP-like fingerprinting can be used for signing and encryption in the trust graph. Don't want to keep someone else's data anymore? Just unlink that folder name from all your views and its space will eventually get re-used.

Remember the old joke about "how big of a disk do I need to download the Internet"? That's a stupid joke, The Internet Archive does just that, in fact it saves multiple Internets through time. The whole web can be one giant archive. Not everyone has to store everything, but together we can have enough redundancy that no one need ever lose data again. Seed boxes can set who, what, and how deep to freeze. However, I am not the only one working on such systems, so I may not be first to market with my DHT-FS, but the distributed data revolution is as inescapable for any species as the discovery of nuclear power is.

Your generation is the first one growing up with a world-wide information network. You have many growing pains ahead as culture must adjust to the advances afforded those who survive into the Age of Information. Your publishing models will be remade, your education systems will be transformed, your economies will scream as those not agile enough seek to prevent rapid progress, your governments will seek to control all the newfound power for themselves, but fear not, the changes will occur: Life itself is decentralized. A world wide distributed file system is what the Internet deserves, and it will happen sooner or later. It is the natural progression of technology. The "best effort" routing is an advantage you will eventually leverage adequately whether you want to or not. The speed limit of light will ensure this happens as you reach for the stars. You will have settlers off-world soon, and they will want to access all of Humanity's information too. Thus, this type of system is inevitable, for any space faring race.

The sooner you learn to separate space from time and implement the delay tolerant space Internet on Earth, the better; The DTN will force you to separate name from location, to leverage deduplication. I know it, NASA knows it, everyone knows this is the true answer, all except SEO gurus apparently.

Re:The true answer is yet to come: DHT-FS (1)

amaurea (2900163) | about 6 months ago | (#46813237)

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 client, not a server or peer" asymmetric internet connections?

Re:The true answer is yet to come: DHT-FS (0)

Anonymous Coward | about 6 months ago | (#46813849)

How about, everyone hosts a few blocks of random 4096 bit data. Now, to make any possible file, all you need to do is download the blocks from around the Internet. For example, you could be making an 11K file by doing this:

whizzo://4
whizzo://10738
whizzo://28 ...you just downloaded 12K of data, throw away the last 1K and you've got your 11K file. All you needed to remember to do this was "4,10738,28", which is a lot less than 11K (although you might want to add a hash to the end of the list to make sure the blocks you got were the right ones). Since there are "only" 7.9228163e+28 possible blocks, it's something that we all need to help out on ;-)

Come to think of it, you could presumably seed a random number generator with the block numbers - then you don't need to bother with the downloading step because you can generate them yourself.

Re:The true answer is yet to come: DHT-FS (0)

Anonymous Coward | about 6 months ago | (#46814757)

Brilliant! You've invented perfect compression of random data. Better patent it quick.

Re:The true answer is yet to come: DHT-FS (0)

Anonymous Coward | about 6 months ago | (#46815163)

Well... it is happening "on the internet" so chances of GP acquiring a patent are rather high

Re:The true answer is yet to come: DHT-FS (1)

Ralph Spoilsport (673134) | about 5 months ago | (#46816951)

That's all fine, until the gov't shuts off the internet, and then you're separated from your data, and in your scheme, even a working computer.

Re:Lovely Concept, but the true answer (1)

gsslay (807818) | about 6 months ago | (#46813611)

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.

Good. (-1)

Anonymous Coward | about 6 months ago | (#46810527)

That's good.

And what happens when... (1)

PmanAce (1679902) | about 6 months ago | (#46810537)

...someone types http : //tech.slashdot.org/story/14/04/21/2218253/404-no-more-project-seeks-to-rid-the-web-of-404-not-found-pages-but-really-is-it-going-to-work-with-this-amazing-new-link?

Clippy (2)

Tablizer (95088) | about 6 months ago | (#46810541)

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:Clippy (-1)

Anonymous Coward | about 6 months ago | (#46810635)

Bitch. We all know you take a faggot dick up the asshole. Don't even act like you're straight.
 
So shut the fuck up and go back to sucking faggot cock.

Re:Clippy (2)

Z00L00K (682162) | about 6 months ago | (#46812585)

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.

Re:Clippy (0)

Anonymous Coward | about 5 months ago | (#46816481)

Many free DNS resolvers do this, including OpenDNS and DNS Advantage.

Actual Utility? (3, Insightful)

ctishman (545856) | about 6 months ago | (#46810543)

Given the choice to display either out-of-date information (potentially causing liability or other miscommunication) or simply putting up a catch-all branded error page with a link back to the site's home, I'm not sure what sort of organization would choose the former.

Re:Actual Utility? (1)

SpaceLifeForm (228190) | about 6 months ago | (#46811895)

NSA

Re:Actual Utility? (1)

BitZtream (692029) | about 6 months ago | (#46814055)

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 (4, Insightful)

Anonymous Coward | about 6 months ago | (#46810547)

We already have redirects. They work just fine.

Re:Um, 301 and 302 (3, Interesting)

Cloud K (125581) | about 6 months ago | (#46810877)

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:Um, 301 and 302 (1)

erice (13380) | about 6 months ago | (#46810923)

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 target page is the same as the creation date of the source. However, it is PITA and many pages are static.

Re:Um, 301 and 302 (1)

drinkypoo (153816) | about 6 months ago | (#46813975)

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 (4, Insightful)

bloodhawk (813939) | about 6 months ago | (#46810559)

Great so now instead of getting a 404 to know I am accessing old or removed content I will now get out of date and potentially wrong content instead of being informed of the error.

Re:what a terrible idea (5, Insightful)

failedlogic (627314) | about 6 months ago | (#46810631)

This would also make deletion of content on the web more difficult.

Re:what a terrible idea (0)

Anonymous Coward | about 6 months ago | (#46810707)

Network Solutions must be sponsoring the project.

it's worse than that (0)

Anonymous Coward | about 6 months ago | (#46810905)

What happens if the original site goes out of business and a new company buys the domain name?

Now imagine the hilarity if a G-rated website is bought by an X-rated website (or more amusingly, vice versa). I can see some idiot representative trying to pass a law saying that websites are required to figure out which defunct version of the website the 404 URL refers-to and redirect the user to content appropriate to the website that the user intended. :D!

Re:it's worse than that (1)

jafiwam (310805) | about 6 months ago | (#46811205)

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:what a terrible idea (1)

bill_mcgonigle (4333) | about 6 months ago | (#46810937)

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. (3, Insightful)

rogoshen1 (2922505) | about 6 months ago | (#46810605)

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 (3, Insightful)

Bogtha (906264) | about 6 months ago | (#46810609)

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 (3, Insightful)

Imagix (695350) | about 6 months ago | (#46810617)

The proposal doesn't say a whole lot about why one would want to do it. So I can attach a date to a link. How does this guarantee that _those_ links won't die?

Re:Pretty thin on why (2)

tomachi (1328065) | about 6 months ago | (#46811769)

Nobody will bother implementing this. The first example they gave (Nearly 50 percent of the hyperlinks in Supreme Court decisions no longer work) is actually solved by the following process: make a backup of the webpage in question during the Supreme Court case. I like the fact I can change content and correct spelling mistakes live on the web.

404 no more! Make it 600 instead! (0)

Anonymous Coward | about 6 months ago | (#46810677)

404 no more! Make it 600 instead!

Content hosted where? (0)

Anonymous Coward | about 6 months ago | (#46810685)

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?

Re:Content hosted where? (1)

Em Adespoton (792954) | about 6 months ago | (#46811103)

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 go down.

Since finding that page requires some sort of a link, maybe whoever provides the link should cache the page they link to, and provide that cache as the alternative if the original 404s? If you've got it bookmarked, the cache would be in the bookmark (also doubles as offline reference); if it's Google search, they've already got the cache -- if it's some blog, they've cached the basic HTML output of the target page. Of course, this tramples all over copyright and security issues (new attack vector: craft a page that infects sites that linkcache it), so won't likely fly. Easier just to use Errorzilla and call it a day.

Xanadu (2)

Rhymoid (3568547) | about 6 months ago | (#46810693)

I think Ted Nelson et al. would love to say "I told you so [wikipedia.org] ."

Re:Xanadu (-1)

Anonymous Coward | about 6 months ago | (#46810731)

Do you like shit logs in your mouth?

Re:Xanadu (-1)

Anonymous Coward | about 6 months ago | (#46810855)

SHIT LOGS!!!!!!
 
lolzyousuckadickbitch

I think it's stuff like this that leads to all (1)

Anonymous Coward | about 6 months ago | (#46810709)

sorts of new security exploits. Do we really need it?

Re:I think it's stuff like this that leads to all (1)

BitZtream (692029) | about 6 months ago | (#46814073)

... 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 (2, Insightful)

Hentes (2461350) | about 6 months ago | (#46810797)

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:There aren't many 404s (1)

psmears (629712) | about 6 months ago | (#46813705)

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:There aren't many 404s (1)

BitZtream (692029) | about 6 months ago | (#46814271)

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! (1)

sootman (158191) | about 6 months ago | (#46810839)

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:I *love* attribute hats! (0)

Anonymous Coward | about 6 months ago | (#46811359)

They're Republicans so they can't spell worth a damn. Just look at how the quality of articles has gone down since they took over this site.

Re:I *love* attribute hats! (1)

PaddyM (45763) | about 6 months ago | (#46811425)

The new way to specify no 404:<!(^404$)>

what could possibly go wrong.? (1)

NemoinSpace (1118137) | about 6 months ago | (#46811037)

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 (1)

Osgeld (1900440) | about 6 months ago | (#46811051)

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? (1)

core_dump_0 (317484) | about 6 months ago | (#46811135)

Could the tags instead be used for scammy redirect tricks (like "Open"DNS "search results")?

I'd just be happy with... (1)

argStyopa (232550) | about 6 months ago | (#46811301)

...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)...... (1)

Dan Askme (2895283) | about 6 months ago | (#46811415)

{
          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 some kid who just left highschool.

You know, you could always FIX THE BROKEN LINK! :P

UUIDs as URLs (1)

Sanians (2738917) | about 5 months ago | (#46815523)

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 you'll never again be bothered by having your first choice be unavailable. An added advantage of this is that you can name your site whatever you want regardless of what domain names are available since you've decided that your domain name doesn't have to match your web site's name. Suddenly the fact that virtually every domain name is being squatted upon no longer matters.

HORRIBLE! (0)

Anonymous Coward | about 6 months ago | (#46811731)

There are good reasons for 404! So who decides what YOU get served up when this happens? Can you say "Just Plain STUPID"?

If not, try "NSA"?

Welp (0)

Anonymous Coward | about 6 months ago | (#46811757)

There goes my plan for writing a script that finds every possible three-letter permutation and tries it along with .com .org and .net and tells me if it gets a 404.

Duct tape solution (0)

Anonymous Coward | about 6 months ago | (#46811863)

Similar to how imperative programming doesn't answer all our needs, this solution doesn't either. It would be better to either just accept that sometimes a page doesn't exist or do what I think should be done. Functional html : html pages that look up the link on demand and if its not available throw you out into the 404 with embedded links to all search engines.

410 (1)

hobarrera (2008506) | about 6 months ago | (#46811901)

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 (1)

TrollstonButterbeans (2914995) | about 6 months ago | (#46811987)

HTML was meant to be easy and accessible to all. At least HTML 2 and 3 and maybe even 4. But stick a fork in the HTML dream, it died a long time ago.

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 internet isn't some awesome thing here for us to explore, the internet is an evil corporate device meant to screw the user over by any means possible, whether or not that involves lying "Hey it isn't a 404! Here, go to this evil page you aren't looking for so we get ad displays and our javascript can privacy-rape you!"

Welcome to the 2014 Internet --- the *cannibal internet* that lies to you, tracks you and eats all your rights away so some companies can make a 3/100s of a penny! And if you don't support this, you are part of the "problem".

aw, please don't... (0)

Anonymous Coward | about 6 months ago | (#46812943)

I have a cool 404 set up on my webspace. I know it hardly ever gets a hit, but this project would prevent some random person from getting a smile in their day. There are whole sites dedicated to cool 404's. Again, we are victim to some committe of young framework-trained certified and inexperienced people.

#getoffmylawn

It might take a while to implement (1)

ctrl-alt-canc (977108) | about 6 months ago | (#46813859)

Aboutt 400,000 people live in 404 area! [usa.com]

What about exploit probes? (0)

Anonymous Coward | about 6 months ago | (#46814091)

My websites generate 404s all the time for script kiddies trying out exploits. Why would I change that?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?