At http://commando.io we implement HSTS in the nginx server block:

    # Enable Strict-Transport-Security for one year
    add_header Strict-Transport-Security max-age=31556926;

https://commando.io/ serves up your PHPMyAdmin.

Edit: also, because of HSTS I can only visit your "secure" site and can no longer get to your marketing page to see what it is you do.

Good catch, fixing that now.

I'll just wait a year for the cached HSTS flag to expire ;)

Should be good now. Just working on a solution for GitHub buttons not supported over SSL.

It's worth noting that Rails enables HSTS for the whole domain when you use the following in one of your config files (usually production.rb):

    config.force_ssl = true

And for Flask users there is flask-sslify[0] by Kenneth Reitz for this.

[0] https://github.com/kennethreitz/flask-sslify

I presume something like this is only useful for services like Heroku where you can't set it in your webserver directly?

It's also useful if your app requirements trump deployment requirements. You might want a particular app to always require SSL, regardless of how it is deployed.

Explained HSTS policy in depth. For more information about how to implement it;

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

What is the benefit of using this over simply redirecting / forcing SSL use for form handlers and other sensitive URLs on the application end.

Doesn't this just add more complexity to a problem that is not that hard to solve?

It prevents anyone controlling the DNS resolvers of your clients to redirect to faked HTTP website (of course, only for those of your clients who already visited your real website).

Imagine you're using my WiFi connection. Without HSTS, I could redirect you to a fake http://www.facebook.com to steal your login credentials if you do not notice the login page is not served over HTTPS (and let's be realistic: most non-technical people won't notice something that's supposed to be there, but is not).

FWIW this is called "SSL stripping".