That would be misleading as example.com and www.example.com are not guaranteed to be the same site.

You could say the same for http:// and https://.

I don't think chrome (or any browser) removes https:// from url bars. They only remove http://.

Ah you're right! For some reason I had it in my head that Chrome was hiding that. I really just hate that it hides any part of the full URL.

Doesn’t safari mobile do that?

Safari desktop as well.

No you couldn't, with http vs https you are accessing the exact same resource, just through a different protocol.

Not necessarily. I've written my share of rewrite rules that change behavior based on https vs http.

Imagining that were true, you would never be redirected to an https version of a page.

Well, if the org hosting the content is being nice and following convention, sure.

But, there's nothing stopping me from running a webserver listening on port 80 (so, accessed in the browser at http://example.com) that serves a picture of a baseball. I can also run a webserver listening on port 443 only (with SSL/TLS set up, so accessed in a browser at https://example.com), on the same machine, that serves a picture of a dog instead.

This sort of breaks the rules/conventions though because you expect the resource to be the same by nature of the URL you're using to access it. But nobody has to follow that rule

That's one way to set it up, but there's no guarantee of that. Servers may switch anything based on TLS status or really any other property of a client request.

I agree with this. The people saying it's technically possible to get a different webpage at that resource address are missing the point - it's trivial to do A/B with the same site, same port, same protocol, based on user IP, time of day or a RNG.

The point of URL is to identify a single address owned by one guy. Removing the www subdomain means you have two addresses, possibly owned by two guys.

The protocol name is part of the URL, so it is possible and technically valid that the https version leads to different content than the http version. Some things are certainly different, for example if there are ads and other linked resources on the https page, they all need to go through https, while on http page, there is no such requirement.

Technically I guess you could make it a subdomain but no one would actually do that in a production site and in my 14 years have never seen it used, not to mention that major search engine bots will lookup both. The general user will simply type in the domain name more times than not without the www

`www` used to literally be a different host in a network (and in some cases, I'm sure still is) specifically designated for WWW traffic. Think of universities in the 90s which had their existing infrastructure and an Internet facing host on their primary domain and they want to add a web server. They may have had a firewall, probably no load balances, so routing port 80 around their primary host was much more complicated than just throwing up a new host and DNS entry.

I regularly come across sites that only work with "www.". Common with university sites that use the subdomain hierarchy a lot. For extra fun, make the behavior reversed depending on if you are inside or outside their network.

Same with my uni. And then you have sites that only work with, and others that only work without the www.

But it makes sense. the first subdomain before the uni domain specifies the faculty, many of which have their own datacenters. Then many of those have yet their own servers in their network, and often www. is one added later on.

My uni makes this extra fun with different sites on http and https.

Oh yeah. And then someone enables HSTS and a subdomain doesn't support HTTPS, so now you have to keep a browser around that never ever is allowed to contact the parent site...

Apple actually does this on the iPhone.

I know IE used to do this too.