[w3c/FileAPI] blob: slice() without valid content type yields unexpected results (Issue #177)

Based on my reading of [blob.slice()](https://w3c.github.io/FileAPI/#dfn-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`|:x:|:x:|:x:|
|bad `contentType`|:white_check_mark:|:x:|:x:|

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 ");
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/177

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/177@github.com>