Re: Upgrade mixed content URLs through HTTP header

Hi,

Probably saying something super-naive, but trying anyway.
What about having the described behavior without a new opt-in?

The use case being discussed is moving large bodies of content to HTTPS. 
In the HTTP version of the site, the cross-domain <img> and <script> 
work. If moving naively to HTTPS, these break because of mixed-content 
blocking.
If the HTTPS version of these resources is attempted to be fetched we 
have one of the two outcomes:
1) the resource exists with HTTPS as protocol : Cool, it's all we wanted
2) the resource doesn't exist with HTTPS as protocol : well, whatever, 
the page was going to be broken anyway because of mixed content blocking.

So, good case: better security, all works fine, worst case is as bad as 
the current state of affairs.

David


Le 02/02/2015 16:24, Anne van Kesteren a écrit :
> 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.
>
>

Received on Tuesday, 3 February 2015 21:21:31 UTC