11 ms·
Cool URIs don't change (1998)
- alistairjcbrown 10y agoI remember Jeremy Keith talking about this at dConstruct conference; he put a bet on Long Bets that the URI of the bet wouldn't change [0] [0] - http://longbets.org/601/ http://longbets.org/601/
- sspiff 10y agoI wonder what happens to long bets when the charity of the winner no longer exists by the time a bet ends.
- icebraining 10y agoThis is defined in the rules: 2. The winnings (plus growth) are awarded with fanfare to the winner's preferred charity. The winner, if still alive, can change charities if desired (but not to multiple recipients). If the winner is no longer alive and the originally designated charity is gone or drastically changed, Long Bets may award the winnings to a charity deemed closest to the winner's original intentions. http://longbets.org/procedure/ http://longbets.org/procedure/
- sspiff 10y agoThanks!
- sjwright 10y agoThe most likely change would be for protocol to move from http to https (and for non-secure URIs to be 301 redirected/forced by HSTS) though I don't think that qualifies as a change under their rules.
- oneeyedpigeon 10y agoUnder "Detailed Terms": > A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those conditions.
- jstanley 10y agoInterestingly it only specifies one level of redirection. So if the redirect were from http to https, and then to some other URL, it seems like that would fail to satisfy the requirements as written.
- oneeyedpigeon 10y agoI think that's being pedantic; multiple redirects really don't break the spirit of the clause.
- tokenizerrr 10y agoThe bet is for www.longbets.org/601, and does not include a http or https protocol. Amusingly enough www.longbets.org/601 currently redirects to longbets.org/601, though the detailed terms cover this.
- sjmulder 10y agoThe Detailed Terms section makes clear that it's for HTTP: > …entering the characters http://www.longbets.org/601 http://www.longbets.org/601 into the address bar of a web browser or command line tool (like curl) OR using a web browser to follow a hyperlink that points to http://www.longbets.org/601 http://www.longbets.org/601 MUST …
- corford 10y agoA bit meta but can someone tell me if Warren Buffet is on course to win his bet[0]? It's set to expire next year. [0] http://longbets.org/362/ http://longbets.org/362/
- SyneRyder 10y agoThere was an episode of Planet Money just a couple of months ago that says Buffett is indeed on track to win the bet: http://www.npr.org/2016/03/10/469897691/armed-with-an-index-fund-warren-buffett-is-on-track-to-win-hedge-fund-bet http://www.npr.org/2016/03/10/469897691/armed-with-an-index-...
- kriro 10y agoCAGR of the S&P500 from 1/1/2008 until the end of 2015 was 6.5%. No idea what fund of funds they used but it's probably not going to be trivial to beat that (+whatever 2016 holds) over the time span after fees.
- corford 10y agoThanks guys! :)
- paleite 10y agoHe's actually already won. The original URL included www., the current one doesn't anymore.
- mediumdeviation 10y ago> A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those [winning] conditions. The bet (and the referenced article) is about the availability of the resources at the end of those URLs - the URL itself is just a reference, or a pointer if you will to a resource.
- jacobr 10y ago> A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those conditions.
- avar 10y agoI wonder if TBL would have written the same article 10 years later when search engines had gotten much better. It's still an inconvenience when a URL moves, but before the likes of Google that used to be a huge inconvenience and it would often take tens of minutes to track down the new location, now it's on the order of tens of seconds at most.
- ygra 10y agoThat depends very much on the content. If you only have an URL and no hint of the content or title of that page, then finding it may prove difficult.
- TeMPOraL 10y agoSee for example any kind of documentation for any piece of hardware that's older than 5 years. The companies change their support pages structrue so often that it's incredibly hard to track anything down. Cynic in me thinks they're doing it on purpose.
- vidarh 10y agoThose are particularly nasty because model numbers are often so arbitrary that a few years down the line searching for an old model number often becomes a near impossible quest of wading through stuff related to newer models with nearly the same model number.
- dredmorbius 10y agoIt's a place where metadata can prove useful. Sci-Hub works largely through an applied identifier, DOI (though URLs also work), which is a unique-per-article identifier present since the 1990s. Earlier gets a bit difficult. Title, author, date, and publisher, you know, what your uni essays instructor always insisted on for footnotes, are pretty good identifiers, and will likely be meaningfully unique. Adding a publication location (as in a newspaper byline) also helps. Ironically, many news organisations fail to include such information not only on individual articles but anywhere apparent on their website. You'll get city, and possibly county, but not a state or province or country. This in an age of, literally, worldwide access. Otherwise, The Internet Archive does yoeman's work in creating a permanent record, where they're allowed to.
- nxzero 10y agoIdea that something cool would stay cool forever sounds like oxymoron. For example, Yahoo.com has remained the URI for Yahoo's homepage and will continue to until it's the 404 page. Yahoo.com is not cool.
- rimantas 10y agoNo, the idea is that URL that don't change are cool.
- nxzero 10y ago>> "No, [repeat idea]." Is not a meaningful response to the claims I presented. At the point that I'm able to swap two resource with another and only reason to believe that a given resource is in fact the resource I referenced is the fact that the unique identifiers are the same means it's in fact useless as an indentifier. In fact, I would claim that the whole idea of URIs as currently used is malformed, since it fails to allow a user to be able to know the resource reference is in fact the resource received.
- chriswarbo 10y agoThe "cool URLs" idea doesn't (AFAIK) cover mutability and temporal issues. In 1998, "yahoo.com" referred to the homepage of Yahoo!. In 2016, "yahoo.com" still refers to the homepage of Yahoo!. The content of the page isn't the same, but it's still the same 'entity' (the homepage of Yahoo!). Hence, despite Yahoo! being uncool, and the contents of the Yahoo! homepage being uncool, the URL of the Yahoo! homepage is cool. It would be nice if URLs had a built-in capability to reference immutable versions of things, similar to git references. This is done on niche networks like IPFS (I think) and Freenet. It's easy to imagine a DNS-like layer which sends "pet names" like "yahoo.com" to the latest version, whilst leaving "raw" names alone (like DNS does for IP addresses). With that said, it would also be nice if DOM elements got their own URLs which user agents could load instead of the whole page (imagine anchors but using something like XPath). That would make hyperlinks more useful and bring us a step closer to Xanadu-like behaviour, e.g. rather than copying text from a page and wrapping it in quotation marks, you could embed that element inside (a quotation element inside) your page.
- prashnts 10y agoOh well, Hall of fame #1 leads to a 404 for both links. So, I propose that it should be fair to call it (Hall of fame #1)².
- metafunctor 10y agoIt's the Hall of flame. They are examples of URIs that were changed for no good reason.
- zymhan 10y ago" There is nothing about HTTP which makes your URIs unstable. It is your organization. " I think this could be applied to more than just how companies manage URLs. Also, I'm trying to find a post I recently read that talked about how calling URLs "URI"s is just confusing nowadays since almost everyone still only knows the term URL, and they're functionally interchangeable.
- kerrsclyde 10y agoWhat about case sensitivity? https://www.w3.org/provider/style/uri https://www.w3.org/provider/style/uri doesn't work.
- lewiseason 10y agoWhat about it? That's a different URI.
- miseg 10y agoIt's tough! I have a custom PHP app that includes marketing pages. I'd like to crowbar Wordpress into the server to serve the marketing pages instead, to make it easie to change text over time. A .htaccess set of redirect rules may indeed work, but it's hard work to keep all URLs working.
- nkuttler 10y ago> It's tough! It really depends on which tools you use. Yes, wp has a horrific URL routing mechanism, and on top of that can randomly redirect 404 pages by guessing the target.
- pidg 10y agoAnother addition to their 'Hall of Flame' might be the British Monarchy. A couple of weeks ago, they broke every existing URI when they moved from www.royal.gov.uk to www.royal.uk. Every URL from the old domain gets redirected to the root of the new site. https://www.google.co.uk/search?q=site%3Aroyal.gov.uk https://www.google.co.uk/search?q=site%3Aroyal.gov.uk
- _puk 10y agoNever fear, the Daily Mail will surely make a call to oust the Monarchy on this basis.. You'd think ICANN would have a .monarchy TLD by now mailto:liz@british.monarchy
- coldtea 10y ago>Never fear, the Daily Mail will surely make a call to oust the Monarchy on this basis.. On this basis? The year being 2016, and those being "blue blooded" privileged rulers is not enough?
- _puk 10y agoApologies, I wasn't trying to infer an opinion either way. More an opinion that the decision to provide the worst possible UX has a likelihood of being highlighted by the populist media.
- philjohn 10y agoYou're thinking of the Guardian ... the DM love the royals.
- _puk 10y agohah, I regret the comment either way now!
- iand 10y agoYou'll be pleased to learn that the National Archives keeps an archive of all UK government sites, e.g. http://webarchive.nationalarchives.gov.uk/20130403203037/http://www.royal.gov.uk/Links/Royal.aspx http://webarchive.nationalarchives.gov.uk/20130403203037/htt... See http://nationalarchives.gov.uk/webarchive/ http://nationalarchives.gov.uk/webarchive/
- chias 10y agoInteresting, the link as posted here violates the guidelines. Perhaps you meant to link to https://www.w3.org/Provider/Style/URI https://www.w3.org/Provider/Style/URI ;)
- benjaminjosephw 10y agoA subtle way of airing my own views on the matter... nothing to do with blindly copy-pasting. ;)
- oneeyedpigeon 10y agoWhat's weird is that the URL gives a 'mixed-content' warning in Chrome, supposedly for the logo. But in the markup, that image is reference by a relative URL; I can't figure out why Chrome is trying to load that image via HTTP...
- iancarroll 10y agoSomewhat oddly, the relative path 301s to an HTTP address but is then changed to HTTPS via HSTS.
- wtbob 10y agoOn a related note, URIs shouldn't end in extensions (use content negotiation!), content should be readable without executing code (no JavaScript necessary), content should be available in multiple languages (use content negotiation!), and RESTful interface should offer a simple forms-based interface for testing, &c.
- hwh 10y agoOn the other hand, "extension" is just an interpretation.
- Tomte 10y agoI've settled for "every article has an URL that looks like a folder" (including trailing slash – that particular debate is pointless), only resources like pictures look like a file with extensions. That's easy to achieve with all CMSen, but also trivially done with a static website (the web server is configured to use index.html or whatever you like).
- throwanem 10y ago> RESTful interface should offer a simple forms-based interface for testing There are plenty of tools which can serve this need. Why complicate every implementation with duplicative functionality?
- SilasX 10y agoSo, a spec that doesn't describe the current state of the web at all and which hosts have found unworkable and over-constraining.
- _puk 10y agoUnfortunately not all CDNs respect the Vary:Accept header. I'm sure it's behind the proliferation of the .format extension to determine response type.
- MichaelGG 10y agoContent negotiation for language and format? Not in any human-usable system, please. Sharing a URL then getting content in a different language is incredibly annoying. There may be no alternative for home pages, and using the Accept-Lang header is nicer than using the broken geo system for sure. But it makes no sense to have a link to a document and get completely different content back based on language. And file extensions are needed since browsers don't expose a way to ask for, say, PDFs or images over HTML.
- hyperpape 10y agoOne downside of this: I now feel like I can't create a proper place to keep my writing or other ideas until I carefully think of a URL scheme that I can maintain for eternity.
- tux1968 10y agoYou can always post it again under a new URI and redirect the original to the new more appropriate spot.
- hwh 10y agojust use random numbers. This is meant more seriously than it might sound. But in the field of "persistent identifiers", there's a notion that languages changes over time (a common example being the word "gay"), so introducing meaning into identification schemes might not be a good idea.
- consto 10y agoAlternative why not have both? Use the meaningful url as most links, but have a randomly generated perma link that will always redirect to the same article
- PavlovsCat 10y agoOr sequential numbers, if you don't need to hide anything from being discoverable that way. Or is there another downside to that? I use "slugs" for category type nodes like "photos" or "blog", but I don't give individual "things" a slug (never liked the idea of putting the title into the URL just for SEO). And of course, everything that has a slug always also has the numerical ID and can be reached both ways. Now that I think of it, I might add a table keeping track what nodes slugs were used for, and in case of 404 either redirect when there is only one option, or display all the nodes that once used that slug if there is more than one. Seems like that would be the next best thing to an actually never changing URL, right?
- 10y ago
- tremon 10y agoI wonder if the footnote was also written in 1998: Historical note: At the end of the 20th century when this was written, "cool" was an epithet of approval particularly among young, indicating trendiness, quality, or appropriateness.
- lstamour 10y agoNope. https://web.archive.org/web/19990508205057/http://www.w3.org/Provider/Style/URI.html https://web.archive.org/web/19990508205057/http://www.w3.org... It was added sometime between Nov. 27, 2001 and Dec. 14, 2001: https://web.archive.org/web/20011214140114/http://www.w3.org/Provider/Style/URI.html https://web.archive.org/web/20011214140114/http://www.w3.org... For those wondering like I was (sigh), the typos that appear in the Hall of Flame footnotes when added in early 2000 were mostly fixed sometime in 2001, the last typo "uit" fixed in 2004.
- pimlottc 10y agoThat's somewhat ironic given how durable the word "cool" has been, despite the general trend of slang to go out of style fairly quickly (c.f. def, bully, radical, bodacious, groovy, boss, all that, etc...).
- Communitivity 10y agoIt is confusing to a lot of people, but they aren't functionally interchangeable. Basically you have Uniform Resource Locators (URLs), Uniform Resource Names (URNs), and Uniform Resource Identifiers (URIs). You also have International Resource Identifiers (IRIs), which are URIs with rules allowing for international character sets in things like host names. Every URN and URL is a URI. However, not every URI is a URN, or a URL. A URN has a specific scheme (the front part of a URI before the :), but it does not contain instructions on how to access the identified resource. We humans might automatically map that to an access method in our head (e.g., digital object identifier URNs like doi:10.1000/182, which we who have used DOIs know maps to http://dx.doi.org/10.1000/182 http://dx.doi.org/10.1000/182), but the instruction isn't in the URN. A URL is not just an identifier but also an instruction for how to find and access the identified resource. For example http://example.org/foo.html http://example.org/foo.html says to access the web resource /foo.html by using the HTTP protocol over TCP to connect to IP address which example.org resolves to, on port 80. An example of URIs which are not URLs are the MIME content ids used to mark the boundaries within an email (cid scheme), e.g., cid:foo4%25foo1@bar.net. You can get more information at: https://tools.ietf.org/html/rfc2392 https://tools.ietf.org/html/rfc2392
- andreasvc 10y agoIMHO the distinction between URL and URI is similar to the debate on SI prefixes for bytes, or whether we should insist on calling Linux GNU/Linux; i.e., most people just don't care enough so these things will never gain currency.
- jephir 10y agoYep. The WHATWG recommends just using the term URL instead of URI. > Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest. https://url.spec.whatwg.org/#goals https://url.spec.whatwg.org/#goals
- dingo_bat 10y ago
- thudson 10y agoCool URLs still work in OmniWeb on a NeXT with a decades old bookmarks file: https://www.flickr.com/photos/osr/17082625625/lightbox https://www.flickr.com/photos/osr/17082625625/lightbox The Mondo 2000 interview bookmarks, not so much.
- nathancahill 10y agoAt least one of their example URLs on the page still points (eventually) to the same content: http://www.nsf.gov/cgi-bin/getpub?nsf9814 http://www.nsf.gov/cgi-bin/getpub?nsf9814 Although they seem to have not learned anything, and are now using .jsp instead of .pl.
- prsutherland 10y agoPre-DMCA. If this gets an update, TBL should add legal reasons and law enforcement as a reason for URI change.
- frenchy 10y agoI've always figured an HTTP 410 response would be sufficient for that.
- prsutherland 10y agoI'd still consider a 410 as a broken link. The article states > Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running.
- marssaxman 10y agoNot 451?
- nommm-nommm 10y agoShouldn't there be some tradeoffs? Say I sign up with service x with the name y. My URL is www.x.com/users/y. Years later I delete my account. Someone else signs up with the name y. Now www.x.com/users/y goes to someone else's resources. The old URL is broken. The only way to prevent this is either give the user a url (that they will want to share) that is not meaningful or disallow anybody to sign up with a name that was ever in use and names are a resource that is very limited. Neither seems ideal. I do agree on principal that URLS shouldn't change, though. Hotmail actually has this problem, or at least they used to. They delete accounts that are inactive for a long time and someone else can sign up with that name. The new person can get email addressed to the previous owner.
- krapp 10y ago>Now www.x.com/users/y goes to someone else's resources. The old URL is broken. The URL isn't broken if it just points to a different resource.
- oneeyedpigeon 10y agoI'd rather it broke. If someone linked to the old URL, describing it as "the profile page of an international child murderer", and I later inherited that URL by signing up for the service, I wouldn't be too pleased. The "y" example is confusingly simplistic; the site already has a "can't use duplicate usernames" rule, so 404'ing the original URL isn't 'worse' for anyone than if the original user didn't delete their account.
- nommm-nommm 10y agoSure not technically broken, it is semantically broken as the meaning has changed.
- zeveb 10y agoThe service should not reuse your username for someone else. Or, perhaps, it should not reuse your user ID, and offer a username resolution service?
- zAy0LfpBZLC8mAC 10y ago
- kazinator 10y ago"Except insolvency, nothing prevents the domain name owner from keeping the name." Ah, the halcyon days of the Internet's adolescence. This was before fiascos like Mike Rowe, of Canada, having his mikerowsoft.com taken away.
- andreasvc 10y agoI just learned of this case. I would say he didn't have his domain name taken away, but voluntarily gave it up when he chose to settle (for an X-box...). I've always found it a disappointing aspect of lawsuits that they end up in settlements so often, this would have formed an interesting precedent since he might have had good chances of winning the case (real name, no intention of deception). Shouldn't there be some kind of rule that prevents lawsuits from being settled when it's in the public interest or in the interest of justice?
- kazinator 10y agoSo he just wasn't "cool", and therefore, so weren't his URI's. :) Working definition of "cool URI": * All URI's currently resolving are "tentatively cool". * Any URI that disappears and changes at any time isn't "cool" --- and never was: the "tentatively cool" designation was mistaken all along.
- brightshiny 10y agoThere's RFC 4151 to keep in mind, TagURI, a scheme for URIs that is independent of URL (but can use it too). One reason to use it would be to mark a page as being the same resource even though the domain or URL had changed. http://www.taguri.org/ http://www.taguri.org/ https://en.wikipedia.org/wiki/Tag_URI_scheme https://en.wikipedia.org/wiki/Tag_URI_scheme I wrote a library for it in Ruby which is how I know about it.
- masonlee 10y agoThis is a cool scheme to address the problem of URL-impermanance due to the fact that DNS name ownership/control can change over time. It allows you to specify a URL plus a date. I wrote a short blog post about the problem a few years back, and the Tag URI scheme ended up being one of the best solutions I came across, which is how I know about it. Some links in that post and comments may be of interest to people: https://masonlee.org/2009/08/21/is-the-web-sticky-enough/ https://masonlee.org/2009/08/21/is-the-web-sticky-enough/
- seagreen 10y agoThis is a make-work trap for conscientious people. If it's more efficient for your business/project to change your URIs when going through a website design, go ahead (with the knowledge that you'll lose some traffic, etc.) Seriously, there's no reason to feel guilty over this. It's not your fault, it's the fault of a system that built two UIs into every website (the website's HTML and the URL bar -- the second of which is supposed to be useful for browsing and navigation just like the first). If W3C actually cared about links continuing to work, they would fix it at the technical level by promoting content-addressable links instead of trying to fix it at the social level (which will never work anyway, the diligent people that care about these things will always be just a drop in the bucket).
- nicky0 10y agoWell exactly. You can change your URLs if you want, but it's not cool. You can choose not to be cool.
- seagreen 10y agoWorking on IPFS/Tahoe-LAFS/Camlistore/BitTorrent is cool. Doing make-work isn't.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- oneeyedpigeon 10y agoI work for a publisher that produces several articles a day that include external links for reference. More and more I seem to be coming across cases where those links are now broken. In the near future, I will startup an automated script that checks for broken links (and I'm guessing I may have to get it warning on redirects since certain bad actors use redirects when they should be using 410). When I have some decent results, I'll be ensuring the editorial team is aware of which sites in particular are prone to breaking links, and which they can trust. The net effect will be that we will be less likely to drive traffic to certain domains. Whether enough other people will do this to make any kind of meaningful difference is unknown, but it's certainly better to be a trustworthy site that it can't hurt to link to. On a related note, I learnt this week that taken-down YouTube videos are a PITA. Not only do they give a 200 when requested, they also give zero results when looked-up via the youtube api. Sure, they can still be treated as a 'broken link' from our end, but it would be nice to be able to differentiate between a video that was taken down and one that may never have existed in the first place.
- zeveb 10y agoI was recently digging through my old blog's archives, and it was appalling how many URLs from the early 2000s have completely disappeared, despite the fact that the sites which served them remain — and gratifying when I was able to reload some fringe resource from 1998 or 2003. The Web is about webs of durable readable content, not about ephemeral walled-garden apps.
- ljk 10y ago> The Web is about webs of durable readable content, not about ephemeral walled-garden apps. Facebook is the worst at this. They even require you to have an account and log in to read a public-facing community/restaurant fb page
- _puk 10y agoUnfortunately GitHub seems to be pretty guilty of this too. Lost count of the number of times I've clicked a link in a blog post only to end up with a GitHub 404; I'm sure it is only going to get worse. Most annoying thing with that one is usually simply going to GitHub search and putting in the original 404'd repo name turns up the one I want. I'm sure having the 404 serve up a "did you mean" search result would solve the issue for the most part.
- marssaxman 10y agoI would say "was supposed to be", not "is", but would otherwise agree.
- alpb 10y agoThe example URL they list from w3.org website (http://www.w3.org/1998/12/01/chairs http://www.w3.org/1998/12/01/chairs) is now broken. Great deal of irony.
- gerry_shaw 10y agoIt requires authentication so not broken but still a poor example.
- makecheck 10y agoA lot of missteps in the early days of web technologies have made stable URLs impractical, unfortunately. One problem is that someone decided to include file name extensions. Maybe this happened naturally because web servers made it so easy to expose entire directory structures to the web. And yet, this continues to be used for lots of other things. It is so ridiculous that a ".asp" or ".php" or ".cgi" causes every link, everywhere to depend on your arbitrary implementation details! Another problem is that many software stacks are just not using brains when it comes to what would make a useful URL. Years ago I was very frustrated working with an enterprise software company that wanted to sell us a bug-tracking system and they didn’t have simple things like "server.net/123456" to access bug #123456; instead, the URL was something absolutely heinous that wouldn’t even fit on a single line (causing wrapping in E-mails and such). Speaking of E-mail, I have received many E-mails over time that consisted of like TWELVE steps to instruct people on how to reach a file on the web. The entire concept of having a simple, descriptive and stable URL was completely lost on these people. It was always: 1. go to home page, 2. click here, ..., 11. click on annoying “content management system” with non-standard UI that generates unbookmarkable link, 12. access document. These utterly broken systems began to proliferate and it rapidly reached the point where most of the content that mattered (at least inside companies) was not available in any sane way so deep-linking to URLs became pointless.
- _greim_ 10y agoCan't remember where I first read it but back when "canonical URLs" were finally starting to get traction the saying went that: > The more expensive the CMS, the crappier the URLs.
- SomeCallMeTim 10y ago>A lot of missteps in the early days of web technologies have made stable URLs impractical, unfortunately. Preserving URLs across technology migrations is always possible (assuming the old documents or at least a rough equivalent still exist in the new system), and usually not even hard, to achieve. Rewrites are not rocket science. Assuming short-sighted developers put .php on the end of all the links, migrating to a better system can use rewrite rules that trivially remove any .php ending from a URL, or that remap old folder layouts to new folder layouts. Even if you can't use mod-rewrite because of complexity that it can't handle, all you need is a server with a hash map (or equivalent) that responds with 301 redirects [1] from the old poorly designed link to the newer, cleaner link. The other problem you mention (no deep linking at all) is its own form of stupidity in design, but since the deep links don't even exist, that's a separate issue. [1] https://en.wikipedia.org/wiki/HTTP_301 https://en.wikipedia.org/wiki/HTTP_301