| Internet-Draft | HTTP/3 EXTERNAL_DATA | September 2022 |
| Bishop | Expires 16 March 2023 | [Page] |
In certain applications, it is useful to be able to process data as it arrives out of order in an HTTP message or to generate message body incrementally in small chunks. This document describes an HTTP/3 extension that facilitates partial generation and out-of-order consumption of HTTP/3 message bodies.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 March 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[HTTP3] defines a mapping of HTTP semantics to the QUIC transport protocol [QUIC]. This mapping assumes a fully reliable transport and is most easily used where the payload body is of a size known from the beginning of the response. A fully reliable transport of HTTP data is most useful where the payload will only be useful when fully present or when consumed in a streaming fashion.¶
Some HTTP message bodies are incrementally generated and have an indeterminate size. [HTTP3] requires the use of either multiple length-prefixed DATA frames (increasing overhead) or a DATA frame which is the final frame of the stream (preventing any other frames on the stream).¶
Other HTTP message bodies have a known internal structure, such that fragments received out of order can be usefully consumed based on the offset or other indicators within received data. While [QUIC] permits implementations to expose out-of-order delivery capabilities, the design of HTTP/3 limits their usefulness in HTTP/3 responses.¶
Extensions have been proposed which enable partial reliability in QUIC. However, as HTTP/3 relies on reliable delivery of the frames which make up the request stream, it becomes complex to indicate that loss of only certain pieces of the stream can be tolerated. For many video streaming applications, particularly live content, partial reliability is attractive since content delayed by loss repair is no longer relevant to the recipient, but consumes bandwidth which could instead be used to send newer content.¶
This document permits the payload of a DATA frame to be sent unframed on a separate unidirectional stream. Following the required type byte, this stream can safely be made partially reliable if the QUIC implementations support such a state. The content can be consumed out-of-order if the receiving QUIC implementation exposes this capability. Since there is no requirement to length-prefix the payload, the frame can be used for incrementally-generated responses without losing the ability to send additional frames on the request stream if the need arises.¶
This extension MUST NOT be used unless the peer has declared support for it in their SETTINGS frame (Section 4.2.5 of [HTTP3]).¶
This extension defines a new SETTINGS parameter:¶
The default value is zero. This extension is supported if the value is non-zero.¶
The EXTERNAL_DATA frame indicates the point in a request stream where a certain extent of payload body would be transmitted, but transfers the actual payload body on a separate unidirectional stream. This frame MAY be used instead of the DATA frame.¶
For HTTP messages where the payload has intervening frames (for example, PUSH_PROMISE or DUPLICATE_PUSH frames), multiple EXTERNAL_DATA frames and multiple unidirectional streams can be used just as multiple DATA frames would be in [HTTP3].¶
The EXTERNAL_DATA frame (type=0xF) indicates a unidirectional stream which will convey an arbitrary, variable-length sequences of bytes associated with an HTTP request or response payload.¶
EXTERNAL_DATA frames MUST be associated with an HTTP request or response. If an EXTERNAL_DATA frame is received on either control stream, the recipient MUST respond with a connection error of type HTTP_WRONG_STREAM.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload of an EXTERNAL_DATA frame is a variable-length integer containing a QUIC stream ID. This ID MUST identify a unidirectional stream initiated by the sender of the EXTERNAL_DATA frame. Receipt of an EXTERNAL_DATA frame with a Stream ID of any other type MUST be treated as a stream error of type HTTP_MALFORMED_FRAME.¶
Upon receipt, if the type of the indicated stream is not External Data (0x44),
this MUST be treated as a stream error of type HTTP_UNKNOWN_STREAM_TYPE on the
request stream. The indicated unidirectional stream MAY still be consumed
according to its declared type, if understood.¶
An EXTERNAL_DATA frame is interpreted as if it were a DATA frame whose payload were the full contents of the indicated unidirectional stream. Multiple EXTERNAL_DATA frames MUST NOT indicate the same unidirectional stream; if a subsequent EXTERNAL_DATA frame indicates the same unidirectional stream ID, this MUST be treated as a stream error of type HTTP_WRONG_STREAM_COUNT.¶
An external data stream is indicated by a stream type of 0x44 (ASCII 'D').
There is no additional framing on this unidirectional stream; the entire stream
payload is interpreted as a fragment of the HTTP message body.¶
If there is a long delay between receipt of an External Data stream and the corresponding EXTERNAL_DATA frame, regardless of the order, this places additional stress on the receiver. The receiver SHOULD NOT consume payload from an External Data stream before receiving the EXTERNAL_DATA frame which indicates to which HTTP exchange the body belongs. This permits flow control to limit the amount of data which cannot be reliably interpreted. However, in extreme cases, failure to consume this data could cause connection flow control to prevent the EXTERNAL_DATA frame from being sent. Senders MUST use caution to ensure that flow control credit will be allocated to the EXTERNAL_DATA frame before being allocated to any bytes on the External Data stream.¶
If an EXTERNAL_DATA frame is received which indicates a unidirectional stream which does not arrive in a timely manner, the same mitigations should be employed as if a DATA frame's header arrived but the payload were delayed. A reasonable timeout should be used to ensure that the request and response are transferred in a timely manner.¶
This document registers a new entry in the "HTTP/3 Frame Type" registry defined in [HTTP3].¶
EXTERNAL_DATA¶
0x0F¶
This document, Section 3.1¶
This document registers a new entry in the "HTTP/3 Stream Type" registry defined in [HTTP3].¶
External Data¶
0x44¶
This document, Section 3.2¶