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