HTTP/1 was poorly tested for error handling and as a result implementations are not interoperable. This lack of interoperability reaches Fetch at times. Where HTTP/1 itself takes no stance or implementations cannot follow it, it might make sense to document it in Fetch or at least document it in this issue.

• status-line parsing: Test HTTP parsing web-platform-tests/wpt#5102
• status-code parsing: "A status is a code" doesn't actually mean anything #1142
• message parsing (in particular incomplete responses): Acting on incomplete headers #472
• CR parsing: HTTP: message parsing with CR web-platform-tests/wpt#13524
• 0x00 parsing: Why does headers-normalize-response.htm expect null bytes to be allowed? xhr#165 (comment) (apart from Firefox and a bug in Safari this is pretty close; agreement here is network error)
• field-value is "incorrect" (this might go beyond H/1, not sure): https://fetch.spec.whatwg.org/#concept-header-value (there is agreement on this, modulo 0x00 above)
• Parsing of specific headers (this goes beyond H/1), such as Content-Type and Content-Length: Redesign "extract header values" and "extract header list values" #814

cc @whatwg/http

(Previously there was https://wiki.whatwg.org/wiki/HTTP.)