Re: HSTS Priming, continued.

I think that would introduce what are likely unacceptable latency times for
img, audio, and video contents that are not available over HTTPS but would
otherwise be immediately loaded/allowed over HTTP.

-- Eric

On Wed, Nov 11, 2015 at 1:38 PM, Brian Smith <brian@briansmith.org> wrote:

> Crispin Cowan <crispin@microsoft.com> wrote:
>
>> Dumb/newbie question: wouldn’t HTTPS upgrades be easy if only client
>> browsers tried HTTPS *first* for every resource? Then fail back to HTTP
>> if policy allows, or block if policy disallows mixed content.
>>
>
> I agree that this sounds better to me. In particular, before doing a
> mixed-content subresource load, first try the subresource load over https://.
> If the response has the HSTS header then you are golden. Otherwise, if the
> response is a 2xx without HSTS (but with the expected content-type--no
> sniffing), then it's probably better to just use the HTTPS response anyway;
> it might be the wrong response, but it's probably not going to be much
> worse than the lack of a response that mixed content blocking causes.
> Otherwise, if it is <img>, <video>, <audio>, continue on with the mixed
> content load if you feel like it.
>
> K.I.S.S.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>