Re: Upgrade mixed content URLs through HTTP header

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` twith`https://example.com/test.png`?

Or would this be similar to strict mixed content checking mode, blocking
the requests without degrading the UI?

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Mon, Feb 2, 2015 at 4:24 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Some members of the W3C staff raised this issue the most clearly,
> though I also found out myself while rolling out TLS on whatwg.org and
> various other domains.
>
> When you have lots of legacy pages that all have various subresources,
> upgrading them all to avoid mixed content warnings (or worse,
> failures) can be a pain. You have enabled TLS for the domains your
> subresources come from, but you don't have the possibility of
> upgrading all the links.
>
> For that scenario it would be useful if we had a header that was
> similar to HSTS, but instead applied to the subresources of the
> current document. HSTS does not help as it a) applies only to a single
> host and any cached hosts and b) happens after mixed content per
> recent agreement.
>
> So I think if we introduced an HTTP response header (only takes affect
> if delivered over TLS) like
>
>   TLS-Only: true
>
> we would enable resources such as
>
>   <!doctype html>
>   <title>Hey!</title>
>   <h1><img src=http://elsewhere.example/test alt=Testing></h1>
>   <script src=http://anywhere.example/run></script>
>
> to avoid mixed content warnings without content changes.
>
> This seems fairly trivial to introduce and support and would lower the
> barrier to TLS adoption some more. Especially for web properties with
> lots of legacy resources.
>
>
> --
> https://annevankesteren.nl/
>
>

Received on Monday, 2 February 2015 15:36:31 UTC