{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"Cool URIs do not change","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Author \u2014 Sir Tim Berners-Lee, inventor of URI, URL, HTTP, HTML, and the World Wide Web, current head of W3C. The article was written in 1998 <\/p>\n

What makes a URI 'cool'?
\nOne that does not change.
\nHow do URIs change?
\nURIs do not change: people change them.<\/i> <\/p>\n

In theory, people have no reason to change URIs (or stop maintaining documents), but in practice, there are millions of reasons.<\/p>\n

Theoretically, the nominal owner of a domain name space indeed owns that space and, consequently, all URIs within it. Except for insolvency, nothing prevents the domain name owner from retaining that name. And theoretically, the URI space under your domain name is completely under your control, so you can make it as stable as you like. To a significant extent, the only plausible reason for a document to disappear from the internet is that the company that owned the domain name went out of business or can no longer afford to maintain the server. So why are there so many broken links in the world? Partly it's just a lack of foresight. Here are some reasons you might hear:
\n<\/a><\/noindex><\/p>\n

We just reorganized the site to make it better.<\/h4>\n

\nDo you really think that old URIs can no longer work? If so, then you picked them very poorly. Consider making sure the new ones are preserved after the next redesign.<\/p>\n

We have so much material that we can't keep track of what's outdated, what's confidential, and what's still relevant, so we figured it would be better to just turn it all off.<\/h4>\n

\nI can only sympathize. W3C went through a period where we had to carefully sift through archived materials for privacy concerns before making them public. The decision needs to be made in advance \u2014 ensure that you record an acceptable audience, creation date, and ideally, expiration date with each document. Preserve that metadata.<\/p>\n

Well, we found that we need to move the files\u2026<\/h4>\n

\nThis is one of the lamest excuses. Many don\u2019t realize that web servers allow you to manage the relationship between a URI of an object and its actual location in the file system. Imagine the URI space as an abstract realm, perfectly organized. Then map it to any reality you are actually using to implement it. Finally, inform the web server about this. You can even write a snippet of your server to get everything right.<\/p>\n

John no longer maintains this file; now Jane does.<\/p>\n

Was John's name in the URI? No, the file was just in his directory. Well, that makes sense.<\/p>\n

We used to use a CGI script for this, but now we use a binary program.<\/h4>\n

\nThere\u2019s a crazy idea that script-generated pages should reside in the \"cgibin\" or \"cgi\" area. This exposes the mechanism of how you run your web server. Change the mechanism (even while keeping the content), and oops \u2014 all your URIs change.<\/p>\n

Let\u2019s take, for example, the National Science Foundation (NSF):<\/p>\n

NSF online documents<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nThe first page to start viewing documents clearly won\u2019t remain that way in a few years. cgi-bin<\/code>, oldbrowse<\/code> and pl<\/code>\u00a0\u2014 all of this gives fragments of information about how-we-do-it-now. If you use a page to search for a document, you receive just as poor results first:<\/p>\n
Cryptography and Coding Theory Working Group Report<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\nfor the document's index page, although the HTML document itself looks much better:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nHere, the title pubs\/1998 will give any future archival service a good key to understand that an old classification scheme from 1998 is in effect. Although in 2098 document numbers may look different, I can imagine that this URI will still be valid, and it won\u2019t hinder NSF or any other organization that will maintain the archive.<\/p>\n
I didn\u2019t think that URLs needed to be permanent \u2014 there were URNs.<\/h4>\n
\nThis is probably one of the worst side effects of discussing URNs. Some think that because of research into a more permanent namespace, they can be careless about dangling links since \"URNs will fix all this.\" If you are one of these people, allow me to disappoint you.<\/p>\n
Most of the URN schemes I have seen look like an authority identifier followed by either a date and a string of your choice or just a string of your choice. This is very similar to an HTTP URI. In other words, if you believe your organization will be able to create long-lasting URNs, then prove it now by using them for your HTTP URIs. There is nothing in HTTP that makes your URI unstable. Only your organization can do that. Create a database that maps the document's URN to its current file name, and let the web server use it to actually retrieve the files.<\/p>\n
If you've made it this far, then if you don't have the time, money, and connections to develop any software, you can state the following excuse:<\/p>\n
We wanted to, but we simply don't have the necessary tools.<\/h4>\n
\nAnd one can feel sorry for that. I completely agree. What you need to do is get the web server to instantly process the persistent URI and return the file, wherever it may currently reside in your current crazy file system. You want to store all URIs in a file as a check and continually maintain a database according to its relevance. You want to preserve the relationships between different versions and translations of the same document, as well as keep an independent checksum record to ensure protection against file corruption due to accidental errors. And web servers simply do not come out of the box with these features. When you want to create a new document, your editor asks for a URI.<\/p>\n
You need the ability to change ownership, access to the document, archival-level security, and more in the URI space without changing the URI.<\/p>\n
It\u2019s all too bad. But we will fix it. At W3C, we use the functionality of Jigedit (the Jigsaw server for editing), which tracks versions, and we are experimenting with document creation scripts. If you are developing tools, servers, and clients, pay attention to this issue!<\/p>\n
This excuse also applies to many W3C pages, including this one: so do what I say, not what I do.<\/p>\n
Why should I care?<\/h1>\n
\nWhen you change the URI on your server, you can never fully say who will have links to the old URI. These can be links from regular web pages, bookmarks to your page, or a URI scribbled in the margins of a letter to a friend.<\/p>\n
When someone clicks a link and it's broken, they usually lose trust in the server owner. They are also disappointed\u2014both emotionally and practically\u2014by the inability to reach their goal.<\/p>\n
Many people constantly complain about broken links, and I hope the damage is clear. I also hope the reputational damage to the server maintainer, where the document has disappeared, is equally obvious.<\/p>\n
So what should I do? Design URIs.<\/h1>\n
\nIt's the webmaster's duty to design URIs that can be used in two years, in twenty years, and even in two hundred years. This requires thoughtfulness, organization, and determination.<\/p>\n
URIs change when any information within them changes. It's very important how you design them. (What, design URIs? Do I need to design URIs? Yes, you should think about it). Designing essentially means leaving out any information from the URI.<\/p>\n
The creation date of the document\u2014the date the URI is issued\u2014is something that will never change. It is very useful for differentiating requests that use the new system from those using the old system. It\u2019s a good starting point for a URI. If the document has a date attached, even if it will remain relevant in the future, that\u2019s a good place to start.<\/p>\n
The only exception is a page that is intentionally the 'last' version, such as for an entire organization or a large part of it.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nThis is the last column of Money Daily in the Money magazine. The main reason why this URI doesn\u2019t need a date is that there\u2019s no reason to keep the URI that will outlive the magazine. The concept of Money Daily will disappear when Money ceases to exist. If you want to reference the content, it should be referenced separately in archives:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(Looks good. Assumes that \"money\" will mean the same throughout the existence of pathfinder.com. There\u2019s duplication of \"98\" and an unnecessary \".html\", but otherwise it looks like a strong URI.)<\/p>\n
What to leave aside<\/h4>\n
\nEverything! Besides the creation date, putting any information in the URI invites problems in one way or another.<\/p>\n