upgrade-insecure-request-with-fallback

upgrade-insecure-requests is a great way for sites to upgrade their 
subresources to https without having to change hardcoded http links. 
upgrade-insecure-requests provides a guarantee that no mixed content 
will load and degrade the security UI of a site.  In cases where an http 
subresource cannot be loaded over https, the subresource will simply 
fail to load and any functionality that it provided will be broken.  
Some sites may appreciate this property and want assurances that third 
party content can't degrade the security of their site.  Others may feel 
that they can't afford to have potentially broken functionality.  Or 
they may know of a single, important subresource that isn't available 
over https and not want to spend the time and effort to upgrade the rest 
of their http links to https.  This would prevent those sites from using 
upgrade-insecure-requests.

I propose we add an upgrade-insecure-request-with-fallback option for 
sites and services that can't afford to break functionality but want the 
potential for increased security.  This fallback option can be either a 
separate directive or an attribute on upgrade-insecure-request.  We will 
have to be careful to ensure that we don't break backwards compatibility 
with sites that already set upgrade-insecure-requests and expect it not 
to fallback.  Sites and services that opt into 
upgrade-insecure-request-with-fallback should be aware that they may 
have slightly decreased performance, because in the fallback case there 
will be two roundtrips for the same subresource.

Thoughts?

~Tanvi