Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

I was hoping this would work as a *-src directive, since there are sites
that will (for ever) need to fetch http:// resources over XHR (eg,

On Tue, Feb 3, 2015 at 3:16 PM, Mike West <> wrote:

> I put together a tiny strawman to explore how this upgrade mechanism might
> work: I think it has some
> real potential as a CSP directive, especially in combination with the
> pinning draft which is up for review.
> (Forking the thread, as this diverges a bit from Anne's original intent,
> and I don't want to derail that conversation entirely.)
> --
> Mike West <>, @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 Tue, Feb 3, 2015 at 12:04 PM, Anne van Kesteren <>
> wrote:
>> On Tue, Feb 3, 2015 at 11:53 AM, Mike West <> wrote:
>> > My worry is that we're papering over the problem for newer clients,
>> thereby
>> > removing incentive to fix the problem for existing clients.
>> I don't really see this as a big deal. Compatibility with existing
>> clients is not interesting long term. (If it was we would not have had
>> the Host header, we would not have had SNI, etc.)
>> > While I agree
>> > with Peter's earlier assertion that we shouldn't hold up progress, I
>> think
>> > this is a concern we'd need to address in order to ensure that sites and
>> > applications remain as accessible as possible.
>> >
>> > Ensuring that CSP-Report-Only works correctly is important, for example.
>> I'm not really convinced. Why would there be a report if the content
>> is augmented in such a way that ensures successful fetches? The only
>> reason would be legacy clients (which fade away). Perhaps during the
>> transition user agents could issue a warning of sorts.
>> Say we make this upgrade-downgrade part of CSP. That means Fetch has
>> another CSP hook (somewhere as first step) to "upgrade downgrade
>> URLs". CSP could use that opportunity to return an upgraded URL and
>> issue a warning (or store the warning to be reported later at some
>> synchronization point).
>> --

Received on Tuesday, 3 February 2015 15:41:41 UTC