2

I have a website which supports HTTPS: all pages of the form http://example.com/foo can be accessed as https://example.com/foo (the query will return the same content). That said, the website doesn't contain anything confidential, so there is no strong benefit to using HTTPS.

I would like to advertise the existence of the HTTPS version of the website, but I don't want to force people to use it: some older clients may not support it, some advanced users may prefer not to use it, etc. For this reason I don't want the server to answer unencrypted HTTP requests with a redirect. That said, for users who prefer to use HTTPS, there has to be a way for them to discover that HTTPS is supported. (Web browsers don't take the initiative of trying to upgrade HTTP connections to HTTPS, e.g., because some websites don't serve the same content over HTTPS as they do over HTTP.)

Is there a way for a Web server to advertise that HTTPS is supported (i.e., any request can be done using HTTPS instead of HTTP) without requiring clients to use HTTPS?

The only relevant mechanism I found is the header Upgrade: TLS/1.0 from RFC2817, which can apparently be sent by the server as well as the client. But it doesn't seem obvious to me whether this is commonly used, or supported by Web browsers.

a3nm
  • 868
  • 6
  • 12
  • I've never heard of anybody supporting that usage of Upgrade. And I'm very sorry to hear that you have to support 1990s era clients. – Michael Hampton May 03 '19 at 18:24
  • 1
    BTW, simply not having confidential material on your website does not mean there are no strong benefits to using HTTPS. See [this document](https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https) for more. – Michael Hampton May 03 '19 at 18:31
  • Having content available in both HTTP and HTTPS URLs might lead to duplicate content penalty from Google, which can affect your search engine visibility. – Tero Kilkanen May 03 '19 at 19:00

2 Answers2

4

The following isn't HTTPS specific, but can be used to softly steer clients towards HTTPS.

If you provide the same content under more than one URL (which is the case if you allow HTTP and HTTPS) you should then add a canonical tag to the content you're serving. That canonical tag then identifies the preferred way to access the content.

Let's pretend you own "example.com" and host a website for that. This site is accessible using both HTTP and HTTPS, both "example.com" and "www.example.com" and the homepage is available under "/" and "/default.html" (for whatever historical reasons you might have). Thus the homepage can be accessed using

You then decide that by default everyone should use https://www.example.com/default.html to access your site's homepage, but you don't want to add any redirections.

You can add a the following tag to your homepage's <head> section

<link rel="canonical" href="https://www.example.com/default.html" />

This will tell every webcrawler (i.e. google) and browser that the content it is looking at right now is available at that url. The client software itself can then decide what to do with that information.

The downside is that you'd have to add such a tag to each and every HTML document you're serving and that it only works for HTML.

Andreas Rogge
  • 2,853
  • 11
  • 24
  • Thanks for the extensive answer! I knew already about this, but yeah I'd have wanted something at the level of the HTTP server. Also, afaik, for now no browser uses rel="canonical" links to upgrade to HTTPS. – a3nm May 04 '19 at 07:54
0

Alternatively to the rel="canonical" mechanism, a common solution nowadays seems to be to use the "Upgrade-Insecure-Requests: 1" header (apparently sent by Firefox and Chrome when making plain HTTP requests). This is how these clients advertise that they support HTTPS, and the server should then redirect them to an HTTPS version.

See here for the question of making it work with lighttpd.

a3nm
  • 868
  • 6
  • 12