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.