Hacker News Reader

Comment by DamnInteresting | Hacker News Reader

If the browser uses some technique to detect that www.domain.com is functionally identical to domain.com for a given domain, then I don't see a serious problem with this. But if they are short of that certainty, they're obscuring a critical part of the URL, and harming usability (e.g., if I want to jot down a site's URL for later use, I might get something unexpected).

View on HN

That's not the case. I run a server that does not respond to "www." If I enter "www.myserver.com" into the address bar, I get a DNS lookup failure, but the address bar is now showing "myserver.com." That's damn confusing, and this is an idiotic default on Chrome's part.

That seems like an edge case worth submitting a separate bug for.

It's not an edge case, it's a specific customization required to support Chrome browsers only.

Think public suffixes! It is long, so definitely not an edge case.

You can write a small script to look up all PSL domains and check if the www and APEX domain has the same dns records.

Our implementation (we control 15 or so) does not, have a www-subdomain for the domains. Anybody can register the www-subdomains.

Likewise, something is saying that their bank only works through www.bank.com. But the URL says bank.com. If they try to type in bank.com it doesn't work.

But hey, now we don't have to see www which has been around forever and is a surprise to no one!

Why would you want to do that?

Funny enough, I visited a site for some task or other just yesterday for which I just typed the base domain, and got ... nothing. It still required the "www." prefix -- no redirect, "ANAME" DNS-side hacks, VIPs or anything in place to make the base domain a reachable URL. This new Chrome change, if it's truly doing naive subdomain hiding, would be a really bad UX for sites like that.

From one of the comments there:

http://www.pool.ntp.org vs http://pool.ntp.org ?

One takes you to the website about the project, the other goes to a random ntp server.

Well, browsers already support a better form of this feature. On the server you setup a redirect to your preferred domain. You redirect https://www.example.com to https://example.com or vise versa.

> If the browser uses some technique to detect that www.domain.com is functionally identical to domain.com for a given domain, then I don't see a serious problem with this.

Say, for example, if the canonical URL doesn't have a "www" in it?

If you click into the address bar to copy/paste, the full URL will come back.

On a Mac it requires two clicks.

First click gives you a suggested list of URLs and related searches.

Second click gives you the full domain name.

"If you click into the address bar to copy/paste, the full URL will come back."

Which is also terrible behavior. Unwanted characters hidden into your paste buffer is at best unexpected and capricious behavior and at worst a source of serious, possibly catastrophic consequences (depending on what, and where, you are pasting).

How soon until a doctored up paste buffer contains, by design, a newline character ? I'm sure there must be some use-case that (appears to) call for this ...

Thank you for validating that I'm not the only person who hates Chrome's horrible clipboard behavior. When I highlight something and copy it to my clipboard I expect exactly what I've highlighted to be on my clipboard-- not some editorialized version of it.

Reply on news.ycombinator.com