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>Received on Wednesday, 11 November 2015 20:10:53 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:52 UTC