This is not standardized behaviour, as no RFC document says how a client should behave if the user does not specify the protocol. But probably, in most default configurations, clients try to connect using a unsecure connection (e.g. http://
) first. They just guess you meant to type http://
in front of your URL.
In that case, it's not the client that figures out that this site is available over a secure connection (e.g. https://
), it's the web server that redirects your client's request. So, when typing google.com
into your browsers' address bar, your browser first connects to http://google.com
, and the webserver at google.com
redirects your request to https://google.com
. That's why you still end up on the https://
version of google.
You can even try this by manually typing http://google.com
in your address bar. Google still redirects you over to https://google.com
. But this is not the default behaviour of most webserver software out there, Google had to manually specify a "HTTPS redirect" in their webservers' configuration.
Still, it's possible, that some clients try a https://
-connection first, and only connect over http://
if that fails. That's a more secure behaviour, and although it's probably not the default in most cases, there is e.g. HSTS that allows sites to flag themselves as https://
, and some Sites may even be pre-flagged in the browser. (As @kicken pointed out, thanks!) Then there are browser plugins (e.g. "HTTPS Everywhere" for Firefox) that implement this procedure. Those plugins come with lists of sites that offer https://
-secured connections, and when a user enters the URL of such a site with http://
or with no protocol at the front, the user gets redirected to the https://
version by the browser, not by the webserver, even if the website administrator didn't set up a HTTPS redirection for his site.