W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: X-Content-Type-Options: nosniff

From: Joel Weinberger <jww@chromium.org>
Date: Thu, 02 Apr 2015 19:09:05 +0000
Message-ID: <CAHQV2Knf14LMO7Ckkv99kqsnzg6rQYLaCqeUR8LqB6mVR+y=Qw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>
Anne, could you retry some of that on Chrome Canary? I actually made a few
changes a few days ago that should treat sniff failures as network errors
(see https://codereview.chromium.org/1032033002/). If we're still firing
the load event, that's definitely a bug at this point. In short, yes, I
believe we would support treating them as network failures.

I also noticed the console logging problem you mentioned and just filed a
bug over it: https://crbug.com/473310.

On Thu, Apr 2, 2015 at 3:24 AM Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Apr 2, 2015 at 9:41 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > I've been trying to figure out what this header does in Internet
> > Explorer 11 and Chrome dev and how we could maybe standardize it.
> <img> - Again only Internet Explorer supports this case. The network
> layer check is a filter on supported image formats. E.g. both
> image/png and image/gif MIME types can proceed and will produce a load
> event. However, if both are for a GIF resource that will only decode
> with the image/gif MIME type.
> That distinction would mean it's no longer just something we could
> check in Fetch. It means the image decoder (which typically handles a
> bunch of formats) needs to play an active role too. It's not entirely
> clear to me why it is desirable to be able to enforce a distinction
> between different image formats.
> --
> https://annevankesteren.nl/
Received on Thursday, 2 April 2015 19:09:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:48 UTC