Test the default Content-Type headers of Request and Response objects #29554
Conversation
wpt-pr-bot
requested review from
annevk,
domfarolino,
jdm,
mnot,
youennf and
yutakahirano
| const blob = new Blob([], { type: "a/b; c=d" }); | ||
| const request = requestFromBody(blob); | ||
| assert_equals(request.headers.get("Content-Type"), "a/b; c=d"); | ||
| }, "Default Content-Type for Request with Blob body (set type)"); |
There was a problem hiding this comment.
Can you test a non-canonicalized MIME type, e.g. Text/HTML;Charset="utf-8"? I can't remember whether this should canonicalize (as text/html;charset=utf-8) or be left as-is.
Similarly testing an invalid-but-ASCII MIME type (e.g. "foo") and a Unicode MIME type (e.g. "😋/😁") would be worthwhile IMO.
There was a problem hiding this comment.
MIME types in Blobs are known to be broken, see w3c/FileAPI#43 and in particular w3c/FileAPI#43 (comment). The general consensus in that issue seems to be that Blobs should parse and serialize the MIME type, and some tests were added in #7764, but the spec hasn't been changed yet. So I'd rather not add new tests that contradict the ones from #7764.
| const boundary = (await request.text()).split("\r\n")[0].slice(2); | ||
| assert_equals( | ||
| request.headers.get("Content-Type"), | ||
| `multipart/form-data; boundary=${boundary}`, |
There was a problem hiding this comment.
Super-awesome that the spec mandates a non-canonical MIME type here (with the space) which is inconsistent with the below two tests 😑
There was a problem hiding this comment.
See whatwg/fetch#422. I'm not sure what browsers did when Hixie introduced the boundary parameter to the spec in 2011, but now they're consistent.
| const blob = new Blob([], { type: "a/b; c=d" }); | ||
| const request = requestFromBody(blob); | ||
| assert_equals(request.headers.get("Content-Type"), "a/b; c=d"); | ||
| }, "Default Content-Type for Request with Blob body (set type)"); |
No description provided.