features with requires HTTPS flag are failing

[dstorey]

Steps:

Open insider build of Edge and check if Web Payments are supported

Expected:

PASS

Actual:

FAIL

Reason:

There is a new bit in APIs that require HTTPS to make it so the feature doesn't even show in the type system, so it is not possible to detect via object detection. Edge has implemented this for Web Payments. Chrome hasn't finished this work yet.

The problem is if you type in html5test.com in the browser, it doesn't automatically forward to https via HSTS header, so unless you've manually been to https://html5test.com before, it will stay on the HTTP version. Once you've been to the https version once it will work as expected, but I'd expect most people won't try this.

[NielsLeenheer]

Yeah, this pretty difficult to solve.

Because legacy browser must also be able to connect to the site, and they do not always support modern HTTPS connections and/or modern certificates, I must initially give them the insecure version over HTTP.

What I could do is:

• Automatically redirect a number of modern browser that deal with this issue,
• Or show a popup on the insecure version to invite users to use the secure version.
• Or, maybe both

And I also need to store the used protocol with of each result, so I can determine if there are differences between the two.

[NielsLeenheer]

Come to think of it, if we want data about this, I actually think we should disable HSTS and do not automatically redirect. Just show a very prominent message to users on HTTP that they may get a better score on HTTPS. That way we get scores from both.

[NielsLeenheer]

[dstorey]

Looks like a good solution! How are you planning to record the score? Include both, or just the https version?

[NielsLeenheer]

As mentioned elsewhere, I've removed this warning.

What I do now is:

• Users visits the site with http://
• The site shows a spinner to indicate it is busy calculating the score
• The score is send to the backend marked as "http:"
• A file is requested from the https:// site
• If the request is successful, the browser redirects to https://
• If the request fails, the spinner stops and the scores are shown

So in this case we get both results from http:// and https:// send to the backend. And because the redirect happens while the spinner is still busy, it should feel pretty seamless to the user. And it makes sure it always shows the higher https:// score.

Why not always redirect? Because older browsers may not be able to use the https:// website because it does not support newer versions of TLS, higher bit certificates or even does not have the root certificate in the root store.