the RST bit set if it detects an error with the stream or the HTTP/2 connection. <ins> 8.6. HTTP/2 does not support the 101 (Switching Protocols) informational status code (HTTP). 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). 8.7. In general, an HTTP client is unable to retry a non-idempotent request when an error occurs because there is no means to determine the nature of the error (see HTTP).  It is possible that some server processing occurred prior to the error, which could result in undesirable effects if the request were reattempted. HTTP/2 provides two mechanisms for providing a guarantee to a client that a request has not been processed: Requests that have not been processed have not failed; clients MAY automatically retry them, even those with non-idempotent methods. A server MUST NOT indicate that a stream has not been processed unless it can guarantee that fact.  If frames that are on a stream are passed to the application layer for any stream, then REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame MUST include a stream identifier that is greater than or equal to the given stream identifier. In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection.  Connections that remain idle can become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings. The PING frame allows a client to safely test whether a connection is still active without sending a request. 8.8. This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses. An HTTP GET request includes control data and a request header with no message content and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields.  The HEADERS frame in the following has both the END_HEADERS and END_STREAM flags set; no CONTINUATION frames are sent. Similarly, a response that includes only control data and a response header is transmitted as a HEADERS frame (again, followed by zero or more CONTINUATION frames) containing the serialized block of response header fields. An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA frame having the END_STREAM flag set: Note that data contributing to any given field line could be spread between field block fragments.  The allocation of field lines to frames in this example is illustrative only. A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag set: An informational response using a 1xx status code other than 101 is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames. A trailer section is sent as a field block after both the request or response field block and all the DATA frames have been sent.  The HEADERS frame starting the field block that comprises the trailer section has the END_STREAM flag set. The following example includes both a 100 (Continue) status code, which is sent in response to a request containing a "100-continue" token in the Expect header field, and a trailer section: </ins> 9. This section outlines attributes of the HTTP protocol that improve