[whatwg/fetch] Should Body.formData() always strip the BOM? (#650)

This came up in https://bugs.chromium.org/p/chromium/issues/detail?id=796192. Blink's currently failing some of the tests added in https://github.com/w3c/web-platform-tests/pull/4517 due to multiple issues.

The `\uFEFFtest=\uFEFF` tests, specifically, fail with `Request` and `Response` because the leading `\uFEFF` ends up being stripped when `Body.formData()` is called.

The input string is correctly [parsed as a USVString and encoded in UTF-8](https://fetch.spec.whatwg.org/#body-mixin) as `\xef\xbb\xbftest=\xef\xbb\xbf`, and calling `Body.formData()` with `Content-Type: application/x-www-form-urlencoded` causes it to be [parsed](https://url.spec.whatwg.org/#urlencoded-parsing) and the string to be decoded via [UTF-8 decode without BOM](https://encoding.spec.whatwg.org/#utf-8-decode-without-bom).

Calling `Body.json()` and `Body.text()`, however, decode the same UTF-8 string with [UTF-8 decode](https://encoding.spec.whatwg.org/#utf-8-decode), which does strip the BOM from the beginning when it's present.

I was wondering if this "asymmetry" is intentional, or whether we should be using the same decoding algorithm for all functions mentioned above.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/650