3 ms·

There was never a requirement for www. to be anything other than the bare domain for most people. It became useful because it was synonymous with being a web th

There was never a requirement for www. to be anything other than the bare domain for most people. It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was. This was serendipity, which turned out not to be serendipitous when people had to write it on signs / read it out on an advert etc. I see no reason now to associate www. with the web version of your service. If I receive a request on port 80 or 443 for the bare domain, what's a better option than service the 99% of people who want a webpage? You are splitting hairs on this one.

joan_lm 8y ago
Sure, perhaps there is no reason to associate www. But the issue here is a browser showing an incorrect url.
ergothus 8y ago
> It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was You're missing some history here (or we're talking past one another) Back then ( source: lived through it) subdomains for particular protocols were pretty common (www.example.com, ftp.example.com, gopher.example.com, mail.example.com) were pretty common, though not a requirement at all. Almost all the users were technical, so this helped users AND admins. Plus, machines were FAR less powerful back then, so anything exposed to the "public" probably didn't want to handle multiple purposes anyway. Then non-technical users came in, saw "www.example.com" being used many places, and assumed it was part of the system. New domains either created a "www" subdomain or lost traffic (until browsers started trying to compensate). Note that what we're discussing is a switch in behavior. Prior to what the article is discussing, a browser would try the domain as typed, and if it failed would try prepending "www" AND ADD IT. > I see no reason now to associate www. with the web version of your service First, you still have people that type the "www" automatically because they never learned that was technically incorrect. Second, what if you're reselling subdomains? The concept of "base domain == identity" is relatively recent and possibly temporary. Third, what if you don't HAVE a single "web version of your service"? The internet (and the web) has succeeded (granted, half by accident) by providing loose rules so practices can evolve inside those rules. If we start encoding the current practices in the rules, the rules no longer handle evolution well (or possibly at all). I'm splitting hairs because hairs sometimes matter.

joan_lm 8y ago

Sure, perhaps there is no reason to associate www. But the issue here is a browser showing an incorrect url.

ergothus 8y ago

> It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was You're missing some history here (or we're talking past one another) Back then ( source: lived through it) subdomains for particular protocols were pretty common (www.example.com, ftp.example.com, gopher.example.com, mail.example.com) were pretty common, though not a requirement at all. Almost all the users were technical, so this helped users AND admins. Plus, machines were FAR less powerful back then, so anything exposed to the "public" probably didn't want to handle multiple purposes anyway. Then non-technical users came in, saw "www.example.com" being used many places, and assumed it was part of the system. New domains either created a "www" subdomain or lost traffic (until browsers started trying to compensate). Note that what we're discussing is a switch in behavior. Prior to what the article is discussing, a browser would try the domain as typed, and if it failed would try prepending "www" AND ADD IT. > I see no reason now to associate www. with the web version of your service First, you still have people that type the "www" automatically because they never learned that was technically incorrect. Second, what if you're reselling subdomains? The concept of "base domain == identity" is relatively recent and possibly temporary. Third, what if you don't HAVE a single "web version of your service"? The internet (and the web) has succeeded (granted, half by accident) by providing loose rules so practices can evolve inside those rules. If we start encoding the current practices in the rules, the rules no longer handle evolution well (or possibly at all). I'm splitting hairs because hairs sometimes matter.