0

We're using the HTML5 Application Cache feature:

<html manifest=".appcache">
   ...
</html>

When returning users navigate to this application they will already have all static files cached and the application is therefore loaded without network requests.

Once the application is loaded it will make AJAX requests to load dynamic content, and the browser will check whether the Application Cache manifest is outdated and possibly download a new version of the application in the background.

Many of our users are accessing this application over insecure connections (HTTP, not HTTPS).

We're in the process of introducing HTTP Strict Transport Security (HSTS) on the servers that host the application.

Implementing HSTS means that our servers will handle requests like this:

  • If the request is insecure (HTTP only), then the server will respond with HTTP status 301 and a Location header that redirect to the requested URI but changing scheme to https.

  • Otherwise; if the request is secure (HTTPS) the server will process it as normal but decorate the response with a Strict-Transport-Security header.

So, when a new user open up our application over HTTP they will be redirected to HTTPS instead and then the application cache manifest is installed using the secure location. That's perfect.

However, a returning user (over HTTP) will NOT be redirected to the secure location (because they already have a cached version on the insecure location). The application cache manifest won't load (since it's a redirection). So returning users are stuck with the application version they had cached and they're stuck using HTTP which is no longer allowed. This is very bad.

We need to come up with a way to transition returning HTTP users to the HTTPS version. How would be best do that?

The way I see it there are two problems:

  1. The browser cannot fetch the application manifest (because it is a redirection). It is therefore unable to upgrade the application to a new version.

    We could perhaps overcome this problem by configuring our servers to allow /.appcache to be served over plain HTTP.

  2. Even if we do that, the application will still be accessed at the HTTP location (since that what's cached by the manifest)

    To workaround that, we might have to implement some kind of javascript logic that changes the scheme of document.location.href to HTTPS.

    I don't like this approach, but it's the only one we've got at this point.

Mårten Wikström
  • 11,074
  • 5
  • 47
  • 87

1 Answers1

0

We settled on the following solution to this problem:

When server receive an insecure request to get the application cache manifest (/.appcache in our case), then a 404 response is returned instead of the normal HTTPS redirect (301).

Getting a 404 causes the cached manifest to be stale and the browser will therefore attempt to reload the application on the next refresh, which will cause it to fetch index.html and be redirected to the secure location.

Mårten Wikström
  • 11,074
  • 5
  • 47
  • 87