Re: Upgrade mixed content URLs through HTTP header

On Mon, Feb 2, 2015 at 8:35 AM, Mike West <mkwst@google.com> wrote:

> Would the effect of the header be equivalent to running `s/http:/https:/g`
> on the HTML? That is, at parse time, we would transparently replace `
> http://example.com/test.png` <http://example.com/test.png> twith`
> https://example.com/test.png` <https://example.com/test.png>?
>
> Or would this be similar to strict mixed content checking mode, blocking
> the requests without degrading the UI?
>
> -mike
>


The difference as I understand is I should still be able to see a padlock
even as this evaluates true:
window.location == "http://example.com/";

That is, maintaining the functionality of URIs permanently tied to the
http: scheme, that can't be changed, e.g. <http://www.w3.org/1999/xhtml>
and <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

It isn't the same as a scheme substitution, because (as mentioned) that
would potentially identify a completely different resource. And indeed,
"upgrading" to <https://www.w3.org/1999/xhtml> would fundamentally break
Web browsers. (If a scheme change were all that were necessary, I think
HSTS would fill that purpose, but correct me if I'm wrong.)

Of course, those aren't URLs as they're not intended to be dereferenced,
but there's other examples (like the numerous XML DTDs, also my own
services) that _do_ use http: URLs intended to be dereferenced exclusively
over TLS (or at least in my case). I currently pull this off with
conversion to relative references where possible, and it works well for me,
but I'm becoming afraid this isn't scalable.

This problem is by no means new, it's just seems it's becoming more
pressing as HTTPS Everywhere gains importance: <
https://tools.ietf.org/html/rfc2817>

An extension to HSTS might work; but we might consider a new header
entirely for the server to declare "$some_list of (or all of the) servers
that I link to support TLS, even if http: is used." The user agent could
then connect over TLS and test that assertion for itself. (The rationale
being that otherwise-opaque URLs contain information on how to contact the
resource's authority; and this is adding additional constraints on how to
reach that authority.)

Cheers,

Austin Wright.