Code change:
8.1.1. <del> HTTP/2 removes support for the 101 (Switching Protocols) informational status code (HTTP). </del> <ins> A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). A request or response that includes message content can include a </ins> <del> The semantics of 101 (Switching Protocols) aren't applicable to a multiplexed protocol.  Alternative protocols are able to use the same mechanisms that HTTP/2 uses to negotiate their use (see starting). </del> <ins> header field.  A request or response is also malformed if the value of a header field does not equal the sum of the DATA frame payload lengths that form the content.  A response that is defined to have no content, as described in HTTP, can have a non-zero header field, even though no content is included in DATA frames. Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a StreamErrorHandler of type PROTOCOL_ERROR. For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed response. Endpoints that progressively process messages might have performed some processing before identifying a request or response as malformed.  For instance, it might be possible to generate an informational or 404 status code without having received a complete request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </ins> <del> 8.1.2. </del> <ins> 8.2. HTTP fields (HTTP) are conveyed by HTTP/2 in the HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with COMPRESSION. </ins> <del> HTTP fields carry information as a series of field lines, which are key-value pairs.  For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry maintained at <https://www.iana.org/assignments/http-fields/>. </del> <ins> To improve efficiency and interoperability, field names MUST be converted to lowercase when constructing a HTTP/2 message. </ins> <del> Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase when constructing a HTTP/2 message. </del> <ins> 8.2.1. </ins> HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.