- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 10 Nov 2017 07:49:57 +0200 (EET)
- To: Wenbo Zhu <wenboz@google.com>, Kazuho Oku <kazuhooku@gmail.com>
- CC: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> 1. as I understand, RFC7540 only states that early 2xx responses are > allowed, i.e. when response headers are generated, any pending request body > becomes insignificant. Therefore the explicit tunneling mechanism is > necessary to signal to proxies/frameworks that a full-duplex byte-stream is > being tunneled as a http/2 stream. Yes, full-duplex byte-stream is quote different from http request-response model. 8.1. HTTP Request/Response Exchange https://tools.ietf.org/html/rfc7540#section-8.1 states ------------- An HTTP request/response exchange fully consumes a single stream. A request starts with the HEADERS frame that puts the stream into an "open" state. The request ends with a frame bearing END_STREAM, which causes the stream to become "half-closed (local)" for the client and "half-closed (remote)" for the server. A response starts with a HEADERS frame and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. An HTTP response is complete after the server sends -- or the client receives -- a frame with the END_STREAM flag set (including any CONTINUATION frames needed to complete a header block). A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag). Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons. -------------- / Kari Hurtta
Received on Friday, 10 November 2017 05:50:26 UTC