Hacker News Reader

Comment by amingilani | Hacker News Reader

I switched to Firefox the moment they hid the `www` prefix.

It's not actually a prefix. It's a subdomain, and there is no requirement for actually having it. It's just a convention that a lot of sites follow.

I switched (back) the moment they hid "http/https".

What’s so bad about hiding www? I kind of prefer it hidden

www.example.com and example.com don't necessarily resolve to the same place.

A common convention with system administrators is to have the canonical name at www.* and redirect www-less requests to the former. If you argue that a browser implementation should fix uncommon configurations, I would argue that administrators should fix their configurations in the first place.

You don’t have this issue at all for domains that don’t have a www subdomain.

Furthermore it would be extremely confusing to have different content for www.example.com & example.com.

Yeah, I don't like the current trend to redirect www to root. You can easily doing simple dns-based load balancing by having multiple ip addresses on the www subdomain. You can't do that on root domain, you'll have to use a dedicated load balancer even if all you want is just simple load balancing among a small set of servers. It only benefit cloud vendors and hurt hobbyist/small website operators if this trend continues to the point that visitors expect all websites to be served from root insetad of www.

I also dislike the trend to redirect the 'www' prefix to root.

My company uses DNS load balancing for a root domain, though, so either I'm misunderstanding you or you're mistaken about what's possible here.

We use Constellix's DNS management to have round-robin DNS via multiple A records for 'nxtbook.com'.

If you're thinking of some other form of DNS load balancing, would you please clarify?

Multiple A records is fine on root domain, but root can't use CNAME, which is used by some people to implement their dns load balancing (I use cname so I forgot that you can still do it using A records). By using root domain instead of www, your options for load balancing is diminished.

Edit: another common use case is hosting your static website on S3 or github pages. Typically it's done by adding a cname entry to s3 or github.io (been a while so hopefully I remember it right). You can't do this on root, unless you're using another server as reverse proxy (e.g. cloudflare's cname flattening service). Again, it's benefits cloud vendors (cloudflare got more potential customers by offering this service for free) but ultimately hurt people that want to host their small websites.

Ah, gotcha. We CNAME a lot of things precisely so we don't have to mess with multiple A records.

Definitely simpler, and a good argument against using the root domain.

Thanks for clarifying!

If we could ever be bothered to implement SRV records for http then load balancing and failover could be significantly more straightforward and robust, without worrying about root vs. www at all.

Redirecting a subdomain to root should be a choice not forced.

> I kind of prefer it hidden

But why?

because it's never significant or useful

> because it's never significant or useful

But www.example.com isn't necessarily the same website as example.com.

What's the practical implication of this fact?

That the difference between them should not be hidden.

The fact that www.example.com and example.com resolves to the same place is a happy accident due to someone explicitly configuring it so.

As a practical example, the website for my current employer had not configured their "bare" domain. When applying for a job I decided to check out their website, and copied only the "bare" domain and pasted it in my browser. Didn't work, just timed out.

I tried a few times and through "huh, website down for a few days, that sure doesn't look good". Then on a whim I figured I might try the "full" domain, and sure enough that loaded up straight away.

One of the first things I got done when I was hired was to ensure the "bare" domain worked.

Yeah but would you discover that by looking at the url? In the vast majority of cases it'll be mentally filtered out by the user anyway for the same reason why nobody cares about the http and :// part, they just want to know if it's secured or not.

> Yeah but would you discover that by looking at the url?

If I want to be on www.example.com and I'm actually on example.com, then yes I can discover that by looking at the URL.

You and maybe the 3 other people that might also notice if a site is serving different pages for http vs https. If it's accessible in the browser its already part of the world wide web so what information is it even conveying?

> so what information is it even conveying?

I feel like I'm going in circles.

They're two different web pages. Possibly with entirely different information. Possibly run by entirely different people. Possibly with entirely different trust levels and threats. It conveys which of the two web pages I'm looking at. How is that not useful information?

All WWW was supposed to mean was HTTP accessible. Now that every domain why should a user using a http* browser have to specify that they intend to access it via http* when they have no other choice? Either the server responds or it doesn't. www.foo.com and foo.com both return http traffic then they are both part of the world wide web.

The specific of how you've decided to run your site or serve your pages is irrelevant. You may serve a page depending on if the http request came over port 80 or some other port or via http or https or at this time or that time or other.

I don't think you get it.

www.example.com and example.com might be two different websites.

If you want the content at www.example.com and you go to example.com, then may not get the content that you wanted. One might be a shop selling shoes and the other might be a shop selling hats.

If you want a hat and you go to the one selling shoes then you're going to be disappointed.

'www.' doesn't 'mean was HTTP accessible'. You can make any system HTTP accessible, or not if you want to.

It doesn't matter how you or I set up our websites, or whether you or I think it's a good idea to have different websites at these addresses, it matters how other people set up their websites and if they choose to do this or not. Some do! Therefore the user needs the information.

Anything might be two different websites.

You could send different websites based on what port the request comes from. But doing so would be bad and wrong, and showing the user the outgoing port is definitely not necessary.

> You could send different websites based on what port the request comes from.

But that's you controlling that, as the person running the website.

When it's the user controlling it, by setting which domain to visit, that's in their control, so they need to see it in their UI.

If you're going to reduce to the absurdity of 'anyone could serve anything from anywhere' then why show a domain at all? ebay.com could serve me the content of google.com, so let's not bother with domain names? Is that your argument?

The person controlling the website is responsible for making www and non-www show the same thing, as well as making http and https show the same thing. (Redirects are fine.) A user's ability to affect something doesn't automatically mean it's their responsibility.

I'm not making an argument about what should be shown right now, I just think your argument, based on what "might be different", is pretty flawed.

> The person controlling the website is responsible for making www and non-www show the same thing, as well as making http and https show the same thing. (Redirects are fine.)

But there's no standard that requires this, that I'm aware of.

Chrome are acting like there is, but I believe there isn't.

There's no standard that says you have to deliver the same data to anyone as far as I'm aware. It's still an absolute abomination if http and https are different sites, for example.

The company I worked for had www.* as a web presentation for the SaaS app and SaaS app running on *.

So yeah, hiding www is annoying and confusing in this situation, because Google just assumed something about the web/domains and forced their assumptions on everyone.

... it's the most significant part of the lookup.

Real example of why this is a bad idea: www.cs.usfca.edu is not cs.usfca.edu. The latter doesn't even have a DNS entry set up..

A screenshot of the browser will not show the www, making it more difficult to find the website.

How, in the 21st century, has USFCA not gotten the memo to redirect HTTP requests to a root domain to a default subdomain instead of black-holing them?

At this point, That's just sloppiness on USFCA's part.

Reply on news.ycombinator.com