blob url fetch with no mime type set is undefined

[dlrobertson]

I could be mistaken, but I couldn't find anything that specifies what should be returned when we fetch a blob url that is backed by a blob, but the mime type was not set. I wanted to add a test like the following to web-platform-tests/wpt#33941, but each engine returns a different value for the mime type.

diff --git a/fetch/api/basic/scheme-blob.sub.any.js b/fetch/api/basic/scheme-blob.sub.any.js
index 6e63cbecaa..b25b412507 100644
--- a/fetch/api/basic/scheme-blob.sub.any.js
+++ b/fetch/api/basic/scheme-blob.sub.any.js
@@ -2,7 +2,9 @@
 
 function checkFetchResponse(url, data, mime, size, desc) {
   promise_test(function(test) {
-    size = size.toString();
+    if (size !== null) {
+      size = size.toString();
+    }
     return fetch(url).then(function(resp) {
       assert_equals(resp.status, 200, "HTTP status is 200");
       assert_equals(resp.type, "basic", "response type is basic");
@@ -42,4 +44,8 @@ invalidRequestMethods.forEach(function(method) {
   checkKoUrl(URL.createObjectURL(blob2), method, "Fetching [" + method + "] URL.createObjectURL(blob) is KO");
 });
 
+var blob3 = new Blob([]);
+checkFetchResponse(URL.createObjectURL(blob3), "", "application/x-unknown-content-type", null,
+                  "Fetching [GET] URL.createObjectURL(blob3) is OK");
+
 done();

Content-Type value	browser
application/x-unknown-content-type	firefox
null	chrome
""	safari

Please let me know if I've missed something!

[annevk]

Hey @dlrobertson, thank you for looking into this.

Looking at https://w3c.github.io/FileAPI/ and https://fetch.spec.whatwg.org/#concept-scheme-fetch Safari would be correct here. I could see adopting Chromium's behavior whereby we special case the empty string value though and not set the Content-Type header in that case, especially as the empty string does not end up parsing like a successful MIME type according to https://mimesniff.spec.whatwg.org/#parse-a-mime-type.

Making up a MIME type as Firefox does could be acceptable, but seems a little weird and non-standard.

@youennf @KershawChang thoughts?

[dlrobertson]

Looking at https://w3c.github.io/FileAPI/

Thanks! I hadn't thought to look at this.

I also should have noted that when returning a empty blob through https://fetch.spec.whatwg.org/#concept-body-consume-body and https://fetch.spec.whatwg.org/#concept-body-package-data via Request.blob() all engines return an empty string.

[KershawChang]

Making up a MIME type as Firefox does could be acceptable, but seems a little weird and non-standard.

I don't have a strong opinion here, but I think an empty string is a better option.

[lucacasonato]

For reference, Deno and Node (undici) both agree with the WebKit / spec behaviour here. No strong opinion from me, but I have a slight preference for the empty string.

[dlrobertson]

Some of the tests from this issue are posted in web-platform-tests/wpt#35469

[annevk]

@domenic could you maybe figure out who from Chrome would be best to follow up here? Thanks!

[ayuishii]

Aligning to empty string sounds reasonable to us, created a ticket to track in chromium (https://crbug.com/1370846).

[dlrobertson]

Created web-platform-tests/wpt#36243, but there are certainly some extra cases that would be interesting to test, that the patch does not currently cover. Feedback would be greatly appreciated!

My simple local tests of a iframe including a blob without a type set also yielded interesting results:

Blob containing a png image

Engine	Result
Gecko	image is shown
Webkit	image is downloaded
Blink	binary image data is shown as text

Blob containing basic html

Engine	Result
Gecko	page is shown
Webkit	page is downloaded
Blink	page is shown as text

[annevk]

I suspect the iframe-related results are not really about blob: URLs but more about how navigation differs between browsers for certain resource types. (Also worth sorting out, but a separate issue.)

[annevk]

@dlrobertson will you file a bug against Firefox for this? I think with that we can close probably this now that the tests have landed?

[dlrobertson]

will you file a bug against Firefox for this?

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1771423

I think with that we can close probably this now that the tests have landed?

👍 Thanks for walking me through the workflow for interop issues!