blob: fetch of slice() without valid content type yields unexpected results

[dlrobertson]

Based on my reading of blob.slice(), it seems that the resulting blobs content type should be the empty string under the following cases:

1. contentType is not given
2. contentType has a value outside the range of U+0020 to U+007E

After writing a simple wpt test, it seems like no browser does 1 and only one does 2.

Test	Safari	Chrome	Firefox
no contentType	❌	❌	❌
bad contentType	✅	❌	❌

Note that in each of these cases the type value of the slice is the empty string. This issue may be related to #1436.

Just in case the issue is actually my test cases 😄, I've attached the example I used below:

promise_test(function(test) {
  var blob = new Blob(["this has no content type"]);
  let slice = blob.slice(12, 24, "\0");
  return fetch(URL.createObjectURL(slice)).then(function (resp) {
    assert_equals(resp.status, 200, "HTTP status is 200");
    assert_equals(resp.type, "basic", "response type is basic");
    assert_equals(resp.headers.get("Content-Type"), "");
    assert_equals(resp.headers.get("Content-Length"), "12");
    return resp.text();
  }).then(function(bodyAsText) {
    assert_equals("content type", bodyAsText)
  });
}, "Set content type to the empty string for slice with invalid content type");

promise_test(function(test) {
  var blob = new Blob(["this has a content type"], {"type": "application/xml"});
  let slice = blob.slice(11, 23);
  return fetch(URL.createObjectURL(slice)).then(function (resp) {
    assert_equals(resp.status, 200, "HTTP status is 200");
    assert_equals(resp.type, "basic", "response type is basic");
    assert_equals(resp.headers.get("Content-Type"), "");
    assert_equals(resp.headers.get("Content-Length"), "12");
    return resp.text();
  }).then(function(bodyAsText) {
    assert_equals("content type", bodyAsText)
  });
}, "Set content type to the empty string for slice with no content type ");

[dlrobertson]

I originally incorrectly filed this as w3c/FileAPI#177, but @inexorabletash correctly pointed out that in each of the test cases, while the content type from the header was not the empty string, the sliced blob type was.

[inexorabletash]

I commented on the other bug:

I haven't stared at Fetch enough, but it does seem inconsistent - to get a header name should only return null if the header list does not contain the header, yet the "blob" fetch algorithm unconditionally appends Content-Type with the blob’s type. It may be that Fetch needs to define an attempt to parse the type, and on failure not append.

[smaug----]

So what do browsers do then? Note, an upcoming change to Gecko will probably change case 2 to behave like webkit.

[dlrobertson]

So what do browsers do then?

Results of the tests pasted in the issue:

Test	Firefox	Chrome	Safari
no contentType	text/plain	null	application/xml
bad contentType	text/plain	null	""

Note, an upcoming change to Gecko will probably change case 2 to behave like webkit.

👍 with the patch gecko does in fact return "" for both tests.

[annevk]

There's at least two different things here:

1. File API currently doesn't use "parse a MIME type", but it should: Implementations allow all values in type getter w3c/FileAPI#43. (There's already tests for this in WPT.)
2. Fetch should probably special case the empty string value and not set a Content-Type header in that case. I think "we" forgot to account for that case.

[dlrobertson]

The tests from this issue are posted in web-platform-tests/wpt#35469

[dlrobertson]

#1436 had a large amount of overlap with this issue, and the associated wpt tests PR web-platform-tests/wpt#36243 contains tests for this here.

Test	Safari	Chrome	Firefox
Set content type to the empty string for slice with invalid content type	❌	❌	❌
Set content type to the empty string for slice with no content type	❌	❌	❌
Blob.slice should not sniff the content for a content type	✅	❌	❌

Is there a WebKit issue for this? If so, I think we can close this unless we need separate issues from those posted in #1436 for Chrome and Firefox (I plan to do the work for this in https://bugzilla.mozilla.org/show_bug.cgi?id=1771423)?

[annevk]

Filed https://bugs.webkit.org/show_bug.cgi?id=246519. Thanks again Dan!