Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Browsers are not interoperable on navigating to no-Content-Type blob: URLs #10827

Open
domenic opened this issue Dec 6, 2024 · 3 comments
Open

Browsers are not interoperable on navigating to no-Content-Type blob: URLs #10827

domenic opened this issue Dec 6, 2024 · 3 comments
Labels
interop Implementations are not interoperable with each other topic: navigation

Comments

@domenic
Copy link
Member

domenic commented Dec 6, 2024

What is the issue with the HTML Standard?

As described in web-platform-tests/wpt#49553 by @cdumez:

Without specifying the content type, Gecko was treating treating the blob as HTML, Blink was treating it as text and WebKit was treating it as binary and downloading it instead of rendering it inside the iframe.

The code was

i.src = URL.createObjectURL(new Blob(["<body></body>"]));

Anyone have preferences on what the "right" behavior is here?

Based on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13303 Gecko seems to sniff, which seems kind of unfortunate but maybe natural. Chromium always does text/plain which seems kind of nice.

This might be a special-case of more no-Content-Type general navigational sniffing
@domenic domenic added topic: navigation interop Implementations are not interoperable with each other labels Dec 6, 2024
@annevk
Copy link
Member

annevk commented Dec 6, 2024

I have a slight preference for treating it the same way as any other response. (Fixing #4362 will likely make it a somewhat special response, but I don't see a reason to extrapolate from that per se.)

And I think that's what is happening apart from maybe Gecko as text/html is not a safe fallback for lack of Content-Type. There is already this unfortunate difference in behavior between falling back to text/plain and download. We should fix that, but writing good tests for sniffing has been tricky.

cc @smaug---- @asutherland

@asutherland
Copy link

asutherland commented Dec 6, 2024 •
edited
Loading

It looks like Firefox is only sniffing because our Blob channel inherits from a base channel implementation that sniffs rather than an explicit rationale. (Whereas our http channel uses seem much more intentional.)

Which is to say, I'm fine with Firefox not sniffing and just leaving the content type empty or falling back to text/plain or whatever. @smaug---- probably has a better opinion than me on this.

@annevk
Copy link
Member

annevk commented Dec 7, 2024

Oh I see, <body> is one of the few things that can sniff as HTML as per https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource and there's no reason for no-sniff to be set. I'm less sure what ought to be done here then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
interop Implementations are not interoperable with each other topic: navigation
Milestone
No milestone
Development

No branches or pull requests
3 participants
@asutherland @domenic @annevk