19 ms·
Berners-Lee 'Sorry' for Slashes (2009)
- sulam 6y agoI think he can be forgiven for not anticipating the cost of a couple slashes. It's probably not as expensive as the addition of 'null' to ALGOL, and that was actually intended to be very widely adopted!
- ricardo81 6y agoIt's often mentioned that open source has '1000 eyes' to correct and improve things. The web has many more than that, I'm sure he can be forgiven for not anticipating every scrutiny about URIs/HTTP/HTML. Seems like a small nitpick, sites that don't optimise their images or compress text content over the wire puts the space savings from no // into the shade
- owl57 6y agoNote that space in the sense of bytes is not mentioned in the article. Only user-visible things such as space on paper.
- goto11 6y agoI don't think size over the wire is the concern. The annoyance is URL's in print or read aloud and typed manually. Browsers have since alleviated this by adding "http://" http://" automatically when you type a domain name.
- ricardo81 6y agoFair point, especially about the browser. Could be argued that mainstream browser's behaviour is what translated to how people offline communicated URLs. If they assumed http for a URL that was without protocol, then perhaps less people would've felt the need to include the protocol on paper.
- mkagenius 6y ago.
- daffy 6y ago> Also, there are a number of factors at play, a number of different futures that could have been resulted if there were no slashes just by chaos theory[1]. So, speculating in the hindsight is not fruitful. This sounds like an argument that one should do whatever, because whatever can result from it.
- mkagenius 6y ago.
- contravariant 6y agoWell, at the very least you shouldn't attempt to do something under the assumption that you can perfectly predict it's result.
- pjc50 6y agoI don't think it mattered so much for print, but in the early days of the internet you would hear people on the TV laboriously reading out "haich tee tee pee colon slash slash double-u double-u double-u dot contoso dot com". This is why a friend of mine has the email address "dot at dot at dot at". Yes, that's uniquely parseable back to one valid rfc822 address that works. I have occasionally wondered about programming language syntax that might take reading aloud into account. Puncutation ends up sounding like Victor Borge: https://www.youtube.com/watch?v=Qf_TDuhk3No https://www.youtube.com/watch?v=Qf_TDuhk3No and of course Python's indentation is very at risk of ambiguity.
- hotcrossbunny 6y ago+1 just for the Victor Borge reference. Maybe his first ever appearance on HN? Who knows?
- bryanrasmussen 6y agohttps://news.ycombinator.com/item?id=10281306 https://news.ycombinator.com/item?id=10281306
- pjc50 6y ago.. which is also me :)
- imglorp 6y agoMy only hardship with this is about half the population doesn't know the difference between a slash and a backslash, which is probably not their fault because they wouldn't have encountered them outside of typesetting or computing. Which is fine until you hear the TV person above do it wrong. Luckily most browsers figure it out. I like to tell people slash is the one you put in a date.
- coldpie 6y agoThe only place a non-programmer user would encounter a backslash is in Windows (nee DOS) file paths, right? Yet another thing Microsoft has made worse in the world ;)
- osxman 6y ago//Accepted.
- thetanil 6y agohowever Bill \\ Gates shall never be forgiven
- dnautics 6y agoI think you mean Bill \\\\ Gates.
- bryanrasmussen 6y agohmm, yes the \\\\ does make a nice Gate icon.
- rosstex 6y agocries in Python
- technothrasher 6y agoAs I've heard the history, Microsoft tried to use a forward slash for directories in DOS 2.0, but IBM insisted it be a backslash so that it didn't conflict with the parameter switch.
- kiwidrew 6y agoYes, the (recently released) source code for MS-DOS 2.0 is liberally sprinkled with comments that indicate Microsoft fully intended for the path separator character to be '/' and the command-line option designation character to be '-'. Microsoft had to design a new API for DOS 2.0, as this was the first version to support hard disk drives and hence required support for subdirectories to organize the filesystem. The API was intentionally designed to mimic Unix. [1] And it was also intended for devices (such as CON, LPT1, COM1, etc.) to be prefixed with the special directory name 'DEV', as in '/DEV/CON' and '/DEV/LPT1', just to make it feel even more like Unix. [2] Apparently the idea was that MS-DOS would be Microsoft's single-user operating system running on cheap 8088 machines, and Xenix would be their "enterprise" multi-user operating system running on high-end 80286 systems, and programs could target a single common DOS/Xenis API and could be run on either OS. [1] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/SYSCALL.txt#L649 https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... [2] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/SYSCALL.txt#L122 https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/...
- Normal_gaussian 6y agoI'm not so negative. The double slash provides a significant visual differentiator that a single colon would not. It may "waste" paper but it saves time.
- goto11 6y agoIn what way does it save time?
- melvinroest 6y agoNot grandparent but it saves time the same way syntax highlighting saves time. You simply recognize the difference faster. With http://example.com http://example.com it's quicker to distinguish the protocol (http) and the domain name (example.com). Compare that to http:example.com and it might take a bit longer at first glance (to some people), because they read over the : and then need to do a quick linear scan before they spot the : and are then able to distinguish http vs example.com Given that one sees a lot of domain names, I'd say it'd save a few hours of everyone's life in the aggregate.
- goto11 6y agoBut humans rarely need to parse URL's into components but often need to read them aloud or type them. The extra characters make this slower and more error prone. For most user interaction purposes the URL is just an opaque string. Only the browser need to actually parse the URL.
- bobosha 6y agoI wrote my MS dissertation under TimBL at MIT. I was into semantic web technologies in the late aughts and chatted with him few times about the double-slash and web nomenclatures etc. I think this article either exaggerates or misstates his intent. IIRC, his thinking was the double slash was just a continuation of the path operator in *nix and would represent the "hyper" in hypertext.
- tasogare 6y agoIt’s true the semantic web was a far bigger mistake, although he doesn’t seem to be sorry for that yet.
- bobosha 6y agoI really don't think the semantic web was a "mistake" at all. And as much as Sir Tim would hate me for saying this, it was (is) still AI - more correctly Symbolic AI - to collaborate at web-scale. Mind you, back then AI was a dirty word, even at MIT, and we had to couch it as "cognitive computing","distributed intelligence" etc. It is a laudable effort and I still love me some semweb technologies.
- anderspitman 6y agoDon't want to get too far off topic but I'm curious what are your thoughts on Solid?
- bryanrasmussen 6y agoWith the quotes I like the read that Sorry as Not Sorry at all, stop bothering me.
- jttam 6y agoI think the greater sin by far was orienting domain names the way that they are: com.google.www becomes tab-completable from the most generic element to the least generic. www.google.com is .. not like that.
- avindroth 6y agoThat sounds so strange. I wonder if that is because I am used to the www. or because ending urls in .org or .com sounds better (pre-invention)
- projektfu 6y agoProbably for the same reason nobody wrote USA DC, Washington Pennsylvania Ave, 1600 Office of the President President Donald Trump
- jdm2212 6y agoThat's actually how addresses are written in Chinese -- most general to most specific. Super disorienting when you're learning it as an English native speaker.
- longwave 6y agoAcademic networks in the UK[0] actually got this the right way round from the start, but DNS won the battle in the mid 90s. [0] https://en.wikipedia.org/wiki/JANET_NRS https://en.wikipedia.org/wiki/JANET_NRS
- wahern 6y agoThis is just a guess, but reading RFC 819 (https://tools.ietf.org/rfc/rfc819.txt https://tools.ietf.org/rfc/rfc819.txt), which transitioned ARPANET to a hierarchical naming scheme and also predates DNS, the little-endian notation might be a simple artifact of ARPANET's e-mail addressing. E-mail addressing was already user@host, which is basically little-endian. It would be consistent to extend it like user@host.site.network. JANET also used @ notation, but used big-endian notation for the domain, which seems inconsistent, at least from a user's perspective. Wikipedia says JANET's e-mail addressing notation was defined by the "Grey Book", and this Usenet thread, http://neil.franklin.ch/Usenet/alt.folklore.computers/20020906_What_is_the_British_Grey_Book_protocol http://neil.franklin.ch/Usenet/alt.folklore.computers/200209..., says the Grey Book domain notation comes from the Network Independent File Transfer Protocol (NIFTP aka "Blue Book", which was a different protocol from ARPANET's RFC 354 FTP). This 1990 JANET<->ARPANET e-mail gateway document, http://dotat.at/tmp/JANET-Mail-Gateways.pdf http://dotat.at/tmp/JANET-Mail-Gateways.pdf, says that JANET e-mail was transferred using NIFTP, so it would make sense that the domain part of the e-mail address would use NIFTP rules. Both above sources say (explicitly or impliedly) that JANET generally, and NIFTP specifically, were based on X.25, and X.25 uses big-endian addressing. So on JANET the hierarchical naming scheme predated the e-mail addressing scheme[1], whereas on ARPANET the reverse is true. Both formats make sense as path dependent outcomes. [1] Presumably JANET still adopted user@ because the message format was based on RFC 822, according to that gateway document above, but it was still worth partially deviating from RFC 822, which explicitly defines little-endian domain syntax, because of JANET's pre-existing host addressing scheme.
- tannhaeuser 6y agoIf there's anything to "apologize" for with URLs, it would be the use of the ampersand character for separating query parameters, as these are interpreted as SGML ERO (entity reference open) character in SGML default concrete syntax, making SGML parsers see an entity reference in links such as http://bla.bla/doc?param=value&otherparam=othervalue http://bla.bla/doc?param=value&otherparam=othervalue. XML doesn't help here as it rejects the whole string as attribute value. This is also IMHO an oversight in the XML and WebSGML specs (the latter allowing to circumvent the issue via so-called data attributes).
- codesnik 6y agothere were attempts to use ; instead, many query parsers in standard libraries still split parameters pairs on semicolon. But who cares if browsers still generate & in GET forms
- goto11 6y agoURL's were supposed to be universal, not limited to any particular media format. The ampersand have to be escaped as & in SGML/HTML/XML. Other formats will need other escapes - no characters are "safe" in all formats.
- quicklime 6y agoI wonder if slashdot would’ve taken off had it been called “colondot” instead.
- cjdell 6y agoHowever, scheme relative URLs (i.e. //example.com/thing.jpg) are useful in edge cases where you want to request assets using the same protocol as the document, are they not?
- otterlicious 6y agoIn an alternative future where the double slashes didn't exist we would just use the colon. http:example.com/thing.jpg :example.com/thing.jpg
- zeroimpl 6y agoWhat would :443/thing.jpg mean? Is that a port or hostname?
- EADGBE 6y agoAlso, don’t forget user/pass prompt in a URL.
- otterlicious 6y agoThere is no ambiguity. http:username:password@example.com/thing.jpg http:username:password@example.com:8080@example.com/thing.jpg But they might have picked a different delimiter for that in this alternative future. Or perhaps realized it was a bad idea earlier. IPv6 addresses are a different story. We definitely would have chosen a different character to delimit IPv6 addresses in this future.
- otterlicious 6y agoA port. RFC 1912 states "Labels may not be all numbers, but may have a leading digit (e.g., 3com.com)."
- zeroimpl 6y agoFWIW I had googled whether hostnames may be entirely digits before asking this, and this SO answer suggested yes. Perhaps that doesn’t apply to URLs? But to be clear I meant hostname not a FQDN, because obviously there is no ambiguity once a dot is present. https://serverfault.com/questions/638260/is-it-valid-for-a-hostname-to-start-with-a-digit https://serverfault.com/questions/638260/is-it-valid-for-a-h...
- captainmuon 6y agoBut without the double slash, how do you differentiate between: proto:relative_to/current_dir proto:/relative_to/root_of_current_host proto://otherhost/some/resource I admit it is hard to grok in the beginning, but all you need to tell non technical people is "you can leave out the http and www" and "hyphen and slash are different symbols".
- dybfjbxybff 6y agoFrom Berners-Lee's FAQ: https://www.w3.org/People/Berners-Lee/FAQ.html https://www.w3.org/People/Berners-Lee/FAQ.html Q: What is the history of the //? A: I wanted the syntax of the URI to separate the bit which the web browser has to know about (www.example.com) from the rest (the opaque string which is blindly requested by the client from the server). Within the rest of the URI, slashes (/) were the clear choice to separate parts of a hierarchical system, and I wanted to be able to make a link without having to know the name of the service (www.example.com) which was publishing the data. The relative URI syntax is just unix pathname syntax reused without apology. Anyone who had used unix would find it quite obvious. Then I needed an extension to add the service name (hostname). In fact this was similar to the problem the Apollo domain system had had when they created a network file system. They had extended the filename syntax to allow //computername/file/path/as/usual. So I just copied Apollo. Apollo was a brand of unix workstation. (The Apollo folks, who invented domain and Apollo's Remote procedure call system later I think went largely to Microsoft, and rumor has it that much of Microsoft's RPC system was). I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact. But it is too late now. It turned out the shorthand "//www.example.com/foo/bar/baz" is rarely used and so we could dispense with the "//".
- dr_j_ 6y agoGiven the standard RFC, the two initial slashes as in scheme:// are critical in any URL when you need to be able to distinguish between the authority and path component, as in scheme://authority/path as in http://server/file.txt http://server/file.txt. Otherwise it would be impossible to know when the server part finished and the path part began (since the authority or server part is always between the second and third slashes). Given the article, I think we’re very lucky to have ended up with this design. But I suppose we could have also arrived at a syntax where the path begins with the second slash (e.g. scheme:/server/path). In fact scheme:/path is valid syntax and is simply the contracted URL form of scheme:///path so at least by today’s RFC definition, scheme:/server/path wouldn’t work since in this contracted form, the path begins with the very first slash and that ‘server’ bit wouldn’t be a server at all but also part of the path.