[encoding-tests] Avoid content type sniffing snafus (#1675)

The single-byte-raw.py returns a response body that's a sequence of 256 bytes [0x00, 0x01, ... 0xFE, 0xFF] in a text/plain. When attempting to load the content in a frame, Chrome applies logic akin to https://mimesniff.spec.whatwg.org/#sniffing-a-mislabeled-binary-resource which recognizes that payload as containing binary data bytes and  application/octet-stream, and prompts the user to download the binary file instead.

Since the document.characterSet/document.inputEncoding test doesn't actually care about the content, this change just introduces another python file which returns a textual payload.

Notes to reviewers:
* If the intent of this test was to detect encoding sniffing by the UA, then this is all moot (but we should make that clear)
* text-plain-charset.py returns an ASCII response body. It does not attempt to encode it, so this could lead to confusing behavior if re-used in the future in another test with UTF-16. (Asking python to encode the string fails for some labels unknown to python.)
* We could add a query param flag to single-byte-raw.py instead of adding a new file. I'm happy with either.


View on GitHub: https://github.com/w3c/web-platform-tests/pull/1675

Received on Friday, 13 March 2015 17:52:50 UTC