Is there a standard header the server can send in ”plain” HTTP mode to give a hint to the browser that HTTPS is available and recommended?
I already use the HSTS mechanisms that tell a browser to not switch back to HTTP, but they only work when already on a secure connection. Currently I use the Rewrite stuff in Apache to make the client use HTTPS, but I would like a less forcing alternative.
To answer the specific question as asked, there actually is a proposal for something pretty much what you want, namely the HTTP Alternative Services proposed standard from the HTTP Working Group. It was published in its current form just a few months ago, on May 3 2016, and the current Internet-Draft expires November 4 2016.
Given how new it is, I expect UA support to be extremely spotty at best. (Mark Nottingham claims that support has been added to Firefox and Chrome, but doesn't give any version numbers.) Also, it's meant for the UA to interpret, not necessarily for the user to make a choice.
On a more general level, I think you have to consider why you don't want to "force" the UA to use HTTPS. Is it because of the performance cost of HTTPS? (Hint: that's completely negligible these days, especially if you are also able to implement HTTP/2.) Is it because some clients may be unable to use encryption? (Hint: if this is really, truly, a big use case for you, then support the unencrypted TLS cipher suites. I don't recommend that, but it is technically possible in much the same way as driving your car off a cliff is technically possible. At least that way, you should get HTTPS' authenticity guarantees, though not confidentiality.) Is it because you have clients that don't speak SNI? (Then consider allocating an IP address to that all-important web site to support the clients stuck on web browsers 5-10 years out of date.)
Forcing HTTPS has several very real benefits even if you don't have anything "secret" on the site or care about the small Google rank boost.
You can always use a HTTP 307 response to temporarily redirect the client from the HTTP site to the HTTPS site if you want to, but it somewhat defeats the point to combine a temporary redirect to HTTPS with HSTS.
Given that you are already using HSTS, I'd say just set up a HTTP 301 permanent redirection from the HTTP vhost to the HTTPS vhost and call it a day. There is very little reason not to these days.
It sounds like this question is actually asking- is there a header that the browser will use to communicate to the user that https is available and they should make a decision to take an action to use it, for this and that and the other reason.
The answer to that question is no. This is not a question for the app to ask the user, relative to other questions and decisions the app places before users that constitute the purpose of the app.
The app has a responsibility to ensure safety, integrity, confidentiality of its interaction with the user, not ask the user what amounts to a pointless question- do you want your interactions to be confidential, etc. Of course they do.
The app has to use the automated machinery available in the context of the trust boundary it can establish with the browser to ensure these attributes characterise the interaction without the user having to take action.
For that reason, using rewrite rules to provide an http 301 response code to point the browser to https if the user requests http is the right thing to do.
Note that google chrome on its own will start signalling that http only sites are insecure, starting with sites that have logins- like the StackOverflow family.
So don't worry about the user experience or user decisioning part of this. Use http 301 and use other headers like hsts and x-frame-options and content security policy and ensure your users safety.
