Re: [w3c/FileAPI] What should happen when you load a blob URL in an iframe? (#82)

Seems to me like this should be a response with

    Content-Type:

as currently written in the specs linked, because the `type` for a Blob with no type provided is `""`.

So then we land in https://html.spec.whatwg.org/#process-a-navigate-fetch and go off to https://mimesniff.spec.whatwg.org/#computed-mime-type which is not really written on top of the fetch concept of Responses so it's hard to tell what's going on here.  But if we assume that https://mimesniff.spec.whatwg.org/#supplied-mime-type-detection-algorithm step 4 applies, we get an empty supplied-type, which is not a "parsable MIME type" and hence we use undefined as the supplied type.

So then we're back in https://mimesniff.spec.whatwg.org/#mime-type-sniffing-algorithm (which got called by https://mimesniff.spec.whatwg.org/#computed-mime-type which is called by https://html.spec.whatwg.org/#process-a-navigate-response step 4; note that this is before the step 7 quoted above).  This says to do

> https://mimesniff.spec.whatwg.org/#rules-for-identifying-an-unknown-mime-type with the sniff-scriptable flag equal to the inverse of the no-sniff flag

and what that does _really_ depends on what the sniff-scriptable flag is set to.  If that flag is set to true, then anything starting with `"<h1"` gets sniffed as `"text/html"`, per that table.  If it's set to false, then we end up in step 9 and get `"text/plain"` in this case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/82#issuecomment-305869725