< draft-xie-bidirectional-messaging-01.txt   draft-xie-bidirectional-messaging-02.txt >
httpbis Working Group G. Xie httpbis Working Group G. Xie
Internet-Draft F. Frindell Internet-Draft A. Frindell
Intended status: Standards Track Facebook Inc. Intended status: Standards Track Facebook Inc.
Expires: 6 October 2019 4 April 2019 Expires: January 9, 2020 July 08, 2019
An HTTP/2 extension for bidirectional messaging communication An HTTP/2 Extension for Bidirectional Message Communication
draft-xie-bidirectional-messaging-01 draft-xie-bidirectional-messaging-02
Abstract Abstract
This draft proposes a http2 protocol extension, which enables This draft proposes an HTTP/2 protocol extension that enables
bidirectional messaging communication between client and server. bidirectional messaging communication between client and server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 October 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents 1. Introduction
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 HTTP/2 [RFC7540] transports HTTP messages via a framing layer that
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 includes many technologies and optimizations designed to make
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 communication more efficient between clients and servers. These
3.1. Routing Stream and ExStream . . . . . . . . . . . . . . 3 include multiplexing of multiple streams on a single underlying
3.2. Bidirectional Messaging Communication . . . . . . . . . 3 transport connection, flow control, stream dependencies and
3.3. States of RStream and ExStream . . . . . . . . . . . . 4 priorities, header compression, and exchange of configuration
3.4. Negotiate the Extension through SETTINGS frame . . . . 5 information between endpoints.
3.5. Interaction with standard http2 features . . . . . . . 5
4. HTTP2 EX_HEADERS Frame . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. FRAME TYPE Registry . . . . . . . . . . . . . . . . . . 6
5.2. Settings Registry . . . . . . . . . . . . . . . . . . . 6
5.3. Error Code Registry . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction Many of these capabilities are generic and can be useful in
applications beyond web browsing, such as Publish/Subscribe protocols
or RPC. However, HTTP/2 framing's request/response client to server
communication pattern prevents wider use in this type of application.
This draft proposes an HTTP/2 protocol extension that enables
bidirectional communication between client and server.
HTTP/2 is the de facto application protocol in Internet. The Currently, the only mechanism in HTTP/2 for server to client
optimizations developed in HTTP/2, like stream multiplexing, header communication is server push. That is, servers can initiate
compression, and binary message framing are very generic. They can unidirectional push promised streams to clients, but clients cannot
be useful in non web browsing applications, for example, Publish/ respond to them and either accept or discard them silently.
Subscribe, RPC. However, the request/response from client to server Additionally, intermediaries along the path may have different server
communication pattern limits HTTP/2 from wider use in these push policies and may not forward push promised streams to the
applications. This draft proposes a HTTP/2 protocol extension, which downstream client. This best effort mechanism is not sufficient to
enables bidirectional messaging between client and server. reliably deliver content from servers to clients, limiting additional
use-cases, such as sending messages and notifications from servers to
clients immediately when they become available.
The only mechanism HTTP/2 provides for server to client communication Several techniques have been developed to workaround these
is PUSH_PROMISE. While this satisfies some use-cases, it is limitations: long polling [RFC6202], WebSocket [RFC8441], and
unidirectional, i.g. the client cannot respond. In this draft, a new tunneling using the CONNECT method. All of these approaches layer an
frame is introduced which has the routing properties of PUSH_PROMISE application protocol on top of HTTP/2, using HTTP/2 streams as
and the bi-directionality of HEADERS. Further, clients are also able transport connections. This layering defeats the optimizations
group streams together for routing purposes, such that each provided by HTTP/2. For example, multiplexing multiple parallel
individual stream does not need to carry additional routing interactions onto one HTTP/2 stream reintroduces head of line
information. blocking. Also, application metadata is encapsulated into DATA
frames, rather than HEADERS frames, making header compression
impossible. Further, user data is framed multiple times at different
protocol layers, which offsets the wire efficiency of HTTP/2 binary
framing. Take WebSocket over HTTP/2 as an example, user data is
framed at the application protocol, WebSocket, and HTTP/2 layers.
This not only introduces overhead on the wire, but also complicates
data processing. Finally, intermediaries have no visibility to user
interactions layered on a single HTTP/2 stream, and lose the
capability to collect telemetry metrics (e.g., time to the first/last
byte of request and response) for services.
These techniques also pose new operational challenges to
intermediaries. Because all traffic from a user's session is
encapsulated into one HTTP/2 stream, this stream can last a very long
time. Intermediaries may take a long time to drain these streams.
HTTP/2 GOAWAY only signals the remote endpoint to stop using the
connection for new streams; additional work is required to prevent
new application messages from being initiated on the long lived
stream.
In this draft, a new HTTP/2 frame is introduced which has the routing
properties of a PUSH_PROMISE frame and the bi-directionality of a
HEADERS frame. The extension provides several benefits:
1. After a HTTP/2 connection is established, a server can initiate
streams to the client at any time, and the client can respond to
the incoming streams accordingly. That is, the communication
over HTTP/2 is bidirectional and symmetric.
2. All of the HTTP/2 technologies and optimizations still apply.
Intermediaries also have all the necessary metadata to properly
handle the communication between the client and the server.
3. Clients are able to group streams together for routing purposes,
such that each individual stream group can be used for a
different service, within the same HTTP/2 connection.
2. Conventions and Terminology 2. Conventions and Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords *MUST*, *MUST NOT*, *REQUIRED*, *SHALL*, *SHALL NOT*,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this *SHOULD*, *SHOULD NOT*, *RECOMMENDED*, *MAY*, and *OPTIONAL*, when
document, are to be interpreted as described in [RFC2119]. they appear in this document, are to be interpreted as described in
[RFC2119].
All the terms defined in the Conventions and Terminology section in All the terms defined in the Conventions and Terminology section in
[RFC7540] apply to this document. [RFC7540] apply to this document.
3. Solution Overview 3. Solution Overview
3.1. Routing Stream and ExStream 3.1. RStream and XStream
A routing stream (RStream) is a long lived HTTP/2 stream in nature.
RStreams are initiated by clients, and can be routed independently by
any intermediaries. Though an RStream is effectively a regular
HTTP/2 stream, RStreams are recommended for exchanging metadata, but
not user data.
A new HTTP/2 stream called ExStream is introduced for exchanging user A routing stream (RStream) is a regular HTTP/2 stream. It is opened
data. ExStreams are recommended for short lived transactions, so by a HEADERS frame, and *MAY* be continued by CONTINUATION and DATA
intermediaries and servers can gracefully shutdown ExStreams within a frames. RStreams are initiated by clients to servers, and can be
short time. The typical use case can be a subscription or publish independently routed by intermediaries on the network path. The main
request/response in Publish/Subscribe use case, or an RPC call purpose for an RStream is to facilitate XStreams' intermediary
between two endpoints. traversal.
An ExStream is opened by an EX_HEADERS frame, and continued by A new HTTP/2 stream called eXtended stream (XStream) is introduced
CONTINUATION and DATA frames. An ExStream MUST be associated with an for exchanging user data bidirectionally. An XStream is opened by an
open RStream, and MUST NOT be associated with any other ExStream. XHEADERS frame, and *MAY* be continued by CONTINUATION and DATA
ExStreams are routed according to their RStreams by intermediaries frames. XStreams can be initiated by either clients or servers.
and servers. Effectively, all ExStreams with the same RStream form a Unlike a regular stream, an XStream *MUST* be associated with an open
logical stream group, and are routed to the same endpoint. RStream. In this way, XStreams can be routed according to their
RStreams by intermediaries and servers. XStream *MUST NOT* be
associated with any other XStream, or any closed RStream. Otherwise,
it cannot be routed properly.
3.2. Bidirectional Messaging Communication 3.2. Bidirectional Communication
With RStreams and ExStreams, HTTP/2 can be used for bidirectional With RStreams and XStreams, HTTP/2 framing can be used natively for
messaging communication. As shown in the follow diagrams, after an bidirectional communication. As shown in Figure 1 and Figure 2 , as
RStream is open from client to server, either endpoint can initiate long as an RStream is open from client to server, either endpoint can
an ExStreams to its peer. initiate an XStream to its peer.
+--------+ RStream (5) +---------+ RStream (1) +--------+ +--------+ RStream (5) +---------+ RStream (1) +--------+
| client |>--------------->| proxy |>---------------->| server | | client |>--------------->| proxy |>---------------->| server |
+--------+ +---------+ +--------+ +--------+ +---------+ +--------+
v ^ v ^ v ^ v ^
| ExStream(7, RS=5) | | ExStream(3, RS=1) | | XStream(7, RS=5) | | XStream(3, RS=1) |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Figure 1: Client initiates the ExStream to server, after an Figure 1: Client initiates an XStream to server.
RStream is open.
+--------+ RStream (5) +---------+ RStream (1) +--------+ +--------+ RStream (5) +---------+ RStream (1) +--------+
| client |>--------------->| proxy |>---------------->| server | | client |>--------------->| proxy |>---------------->| server |
+--------+ +---------+ +--------+ +--------+ +---------+ +--------+
^ v ^ v ^ v ^ v
| ExStream(4, RS=5) | | ExStream(2, RS=1) | | XStream(4, RS=5) | | XStream(2, RS=1) |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Figure 2: Server initiates the ExStream to client, after an
RStream is open.
Beyond that, clients can multiplex RStreams, ExStreams and regular Figure 2: Server initiates an XStream to client.
HTTP/2 streams into one HTTP/2 connection. This enables clients to
access different services without initiating new TCP connections.
This avoids the latency cost of setting up new connections. This is
more desirable for mobile devices because they usually have longer
RTT and battery constraints. Multiplexing these services also allows
them to share a single TCP connection congestion control context.
As shown in the following diagram, the client can exchange data with 3.3. XStream Grouping
PubSub, RPC and CDN three different services with one TCP connection.
A client can multiplex RStreams, XStreams and regular HTTP/2 streams
into a single HTTP/2 connection. Additionally, all of the XStreams
associated with the same RStream form a logical stream group, and are
routed to the same endpoint. This enables clients to access
different services without initiating new connections,or including
routing metadata in every message. As shown in Figure 3, the client
can exchange data with three different services (PubSub, RPC, and
CDN) using one HTTP/2 connection.
+--------+ RStream (5) +---------+ RStream (1) +----------+ +--------+ RStream (5) +---------+ RStream (1) +----------+
| client |>--------------->| proxy |>---------------->| PUBSUB | | client |>--------------->| proxy |>---------------->| PubSub |
+--------+ +---------+ +----------+ +--------+ XStream (7) +---------+ XStream (3) +----------+
v v ^ ^ v v v v ^ ^ v v
| | RStream (7) / | | \ RStream (5) +----------+ | | | | | |
| +-------------------+ | | +---------------->| RPC | | | RStream (11) | | | | RStream (5) +----------+
| | | +----------+ | +--------------------+ | | +------------------>| RPC |
| XStream (13) | | XStream (7) +----------+
| | | | | |
| Stream (9) | | Stream (7) +----------+ | | |
| Stream (21) | | Stream (9) +----------+
+---------------------------+ +--------------------->| CDN | +---------------------------+ +--------------------->| CDN |
+----------+ +----------+
Figure 3: Client opens multiple RStreams and a HTTP/2 stream Figure 3: Client opens multiple RStreams, XStreams and an HTTP/2
within one HTTP/2 connection. stream within one HTTP/2 connection.
3.3. States of RStream and ExStream Reusing one connection for different purposes saves the latency of
setting up new connections. This is especially desirable for mobile
devices which often have higher latency network connectivity and
tighter battery constraints. Multiplexing these services also allows
them to share a single transport connection congestion control
context. It also opens new optimization opportunities, like
prioritizing interactive streams over streams used to fetch static
content. It also reduces the number of connections that are adding
load to intermediaries and servers in the network.
3.4. Recommended Usage
RStreams and XStreams are designed for different purposes. RStreams
are *RECOMMENDED* for exchanging metadata only, and *SHOULD* be long
lived, as once an RStream is closed any routing information it
carried is lost. Unless a new RStream is re-established promptly, no
new XStreams can be initiated. To keep an RStream open, endpoints
*SHOULD NOT* send a HEADERS or DATA frame containing the END_STREAM
flag. Implementations might require special logic to prevent
RStreams from timing out. For example, refresh the timeouts on
RStreams if a new XStream is exchanged.
By contrast, XStreams are *RECOMMENDED* for exchanging user data, and
*SHOULD* be short lived. In long polling, WebSocket and tunneling
solutions, streams have to be kept alive for a long time because
servers need those streams for sending data to the client in the
future. With this extension, servers are able to initiate new
XStreams as long as RStreams are still open and no longer need to
keep idle streams around for future use. This allows all parties
involved in the connection to keep resource usage to a minimum.
Morever, short lived XStreams make graceful shutdown of a connection
easier for intermediaries and servers. After exchanging GOAWAY
frames, short lived XStreams will naturally drain within a short
period of time.
3.5. States of RStream and XStream
RStreams are regular HTTP/2 streams that follow the stream lifecycle RStreams are regular HTTP/2 streams that follow the stream lifecycle
in [RFC7540], section 5.1. ExStreams use the same lifecycle as described in [RFC7540], section 5.1. XStreams use the same lifecycle
regular HTTP/2 streams, but also depend on their RStreams. If a as regular HTTP/2 streams, but have extra dependency on their
RStream is reset, endpoints MUST reset the ExStreams associated with RStreams. If an RStream is reset, endpoints *MUST* reset the
that RStream. If the RStream is closed, endpoints SHOULD allow XStreams associated with that RStream. If the RStream is closed,
existing ExStreams complete normally. The RStream SHOULD remain open endpoints *SHOULD* allow the existing XStreams to complete normally.
while communication is ongoing. Endpoints SHOULD refresh any The RStream *SHOULD* remain open while communication is ongoing.
timeouts on the RStream while associated ExStreams are open. Endpoints *SHOULD* refresh any timeout on the RStream while its
associated XStreams are open.
A sender MUST NOT initiate new ExStreams if on an RStream that is in A sender *MUST NOT* initiate new XStreams with an RStream that is in
the open or half closed (remote) state. the closed or half closed (remote) state.
Endpoints process new ExStreams only when the RStream is open or half Endpoints process new XStreams only when the associated RStream is in
closed (local) state. If an endpoint receives an EX_HEADERS frame the open or half closed (local) state. If an endpoint receives an
specifying an RStream in the closed or haf closed (remote) state, it XHEADERS frame specifying an RStream in the closed or half closed
MUST respond with a connection error of type ROUTING_STREAM_ERROR. (remote) state, it *MUST* respond with a connection error of type
ROUTING_STREAM_ERROR.
3.4. Negotiate the Extension through SETTINGS frame 3.6. Negotiating the Extension
The extension SHOULD be disabled by default. Endpoints can negotiate The extension *SHOULD* be disabled by default. As noted in
the use of the extension through the SETTINGS frame. If an [RFC7540], section 5.5, HTTP/2 compliant implementations which do not
implementation supports the extension, it is RECOMMENDED to include support this extension *MUST* ignore the unknown ENABLE_XHEADERS
the ENABLE_EX_HEADERS setting in the initial SETTINGS frame. HTTP/2 setting and XHEADERS frame. Endpoints can negotiate the use of this
compliant implementations will ignore the setting if it is unknown. extension through the SETTINGS frame, and once enabled, this
An endpoint can send EX_HEADERS frames immediately upon receiving a extension *MUST NOT* be disabled over the lifetime of the connection.
SETTINGS frame with ENABLE_EX_HEADERS=1.
Endpoints MUST NOT send out EX_HEADERS before receiving a SETTINGS This document introduces another SETTINGS parameter, ENABLE_XHEADERS,
frame with the ENABLE_EX_HEADERS=1. If a remote endpoint does not which *MUST* have a value of 0 or 1.
support this extension, the EX_HEADERS will be ignored, making the
header compression contexts inconsistent between sender and receiver.
If an endpoint supports this extension, but receives EX_HEADERS Once a ENABLE_XHEADERS parameter has been sent with a value of 1, an
before ENABLE_EX_HEADERS, it MUST respond with a connection error endpoint *MUST NOT* send the parameter with a value of 0.
EX_HEADER_NOT_ENABLED_ERROR.
Intermediaries SHOULD send the ENABLE_EX_HEADERS setting to clients, If an implementation supports the extension, it is *RECOMMENDED* to
only if intermediaries and their upstream servers can support this include the ENABLE_XHEADERS setting in the initial SETTINGS frame,
extension. If an intermediary receives an ExStream but discovers the such that the remote endpoint can disover the support at the earliest
destination endpoint does not support the extension, it MUST reset possible time.
the stream with EX_HEADER_NOT_ENABLED_ERROR.
3.5. Interaction with standard http2 features An endpoint can send XHEADERS frames immediately upon receiving a
SETTINGS frame with ENABLE_XHEADERS=1. An endpoint *MUST NOT* send
out XHEADERS before receiving a SETTINGS frame with the
ENABLE_XHEADERS=1. If a remote endpoint does not support this
extension, the XHEADERS will be ignored, making the header
compression context inconsistent between sender and receiver.
The extension implementation should apply stream and connection level If an endpoint supports this extension, but receives XHEADERS frames
flow control, maximum concurrent streams limit, GOAWAY logic to both before ENABLE_XHEADERS, it *SHOULD* to respond with a connection
RStreams and ExStreams. error XHEADER_NOT_ENABLED_ERROR. This helps the remote endpoint to
implement this extension properly.
4. HTTP2 EX_HEADERS Frame Intermediaries *SHOULD* send the ENABLE_XHEADERS setting to clients
only if intermediaries and their upstream servers support this
extension. If an intermediary receives an XStream but discovers the
destination endpoint does not support the extension, it *MUST* reset
the stream with XHEADER_NOT_ENABLED_ERROR.
The EX_HEADERS frame (type=0xfb) has all the fields and frame header 3.7. Interaction with Standard HTTP/2 Features
flags defined by HEADERS frame in HEADERS [RFC7540]. Moreover,
EX_HEADERS has one extra field, RStream ID. It is used to open an XStreams are extended HTTP/2 streams, thus all the standard HTTP/2
ExStream, and additionally carries a header block fragment. features for streams still apply to XStreams. For example, like
EX_HEADERS frames can be sent on a stream in the "idle", "open", or streams, XStreams are counted against the concurrent stream limit,
"half-closed (remote)" state. defined in [RFC7540], Section 5.1.2. The connection level and stream
level flow control principles are still valid for XStreams. However,
for the stream priority and dependencies, XStreams have one extra
constraint: a XStream can have a dependency on its RStream, or any
XStream sharing with the same RStream. Prioritizing the XStreams
across different RStream groups does not make sense, because they
belong to different services.
4. HTTP/2 XHEADERS Frame
The XHEADERS frame (type=0xfb) has all the fields and frame header
flags defined by HEADERS frame in HEADERS [RFC7540], section 6.2.
The XHEADERS frame has one extra field, Routing Stream ID. It is
used to open an XStream, and additionally carries a header block
fragment. XHEADERS frames can be sent on a stream in the "idle",
"open", or "half-closed (remote)" state.
Like HEADERS, the CONTINUATION frame (type=0x9) is used to continue a Like HEADERS, the CONTINUATION frame (type=0x9) is used to continue a
sequence of header block fragments, if the headers do not fit into sequence of header block fragments, if the headers do not fit into
one EX_HEADERS frame. one XHEADERS frame.
4.1. Definition
+---------------+ +---------------+
|Pad Length? (8)| |Pad Length? (8)|
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
|E| Stream Dependency? (31) | |E| Stream Dependency? (31) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
| Weight? (8) | | Weight? (8) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
|R| Routing Stream ID (31) | |R| Routing Stream ID (31) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
| Header Block Fragment (*) ... | Header Block Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Padding (*) ... | Padding (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 4: EX_HEADERS Frame Payload Figure 4: XHEADERS Frame Payload
The RStream specified in EX_HEADERS frames MUST be an open stream. The RStream specified in a XHEADERS frame *MUST* be an open stream.
The recipient MUST respond with a connection error The recipient *MUST* respond with a connection error of type
ROUTING_STREAM_ERROR PROTOCOL_ERROR, if the specified RStream is ROUTING_STREAM_ERROR PROTOCOL_ERROR, if the specified RStream is
missing; or is an ExStream rather than a stream; or is closed or missing, is an XStream rather than a regualr HTTP/2 stream, or is
half-closed (remote). Otherwise, the states maintained for header closed or half-closed (remote). Otherwise, the states maintained for
compression or flow control) may be out of sync. header compression or flow control may be out of sync.
4.2. Examples
This section shows HTTP/1.1 request and response messages that are
transmitted on an RStream with regualar HEADERS frames, and on an
XStream with HTTP/2 XHAEDERS frames.
GET /login HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM
+ END_HEADERS
:method = GET
:scheme = https
:path = /login
host = example.org
{binary data .... } ==> DATA
- END_STREAM
{binary data ... }
Figure 5: The request message and HEADERS frame on an RStream
HTTP/1.1 200 OK HEADERS
==> - END_STREAM
+ END_HEADERS
:status = 200
{binary data .... } ==> DATA
- END_STREAM
{binary data...}
Figure 6: The response message and HEADERS frame on an RStream
The server initiates an XStream to this client.
POST /new_msg HTTP/1.1 XHEADERS
RStream_ID = 3
Host: example.org ==> - END_STREAM
+ END_HEADERS
:method = POST
:scheme = https
:path = /new_msg
host = example.org
{binary data} ==> DATA
+ END_STREAM
{binary data}
Figure 7: The request message and XHEADERS frame on an XStream
HTTP/1.1 200 OK XHEADERS
RStream_ID = 3
==> + END_STREAM
+ END_HEADERS
:status = 200
Figure 8: The response message and XHEADERS frame on an XStream
5. IANA Considerations 5. IANA Considerations
This document establishes a registry for a new frame type, setting, This specification adds an entry to the "HTTP/2 Frame Type" registry,
and error code. the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry,
all defined in [RFC7540].
5.1. FRAME TYPE Registry 5.1. FRAME TYPE Registry
The entry in the following table are registered by this document. The entry in the following table are registered by this document.
+---------------+------+--------------+ +---------------+------+--------------+
| Frame Type | Code | Section | | Frame Type | Code | Section |
+---------------+------+--------------+ +---------------+------+--------------+
| EX_HEADERS | 0xfb | | | XHEADERS | 0xfb | |
+---------------+------+--------------+ +---------------+------+--------------+
5.2. Settings Registry 5.2. Settings Registry
The entry in the following table are registered by this document. The entry in the following table are registered by this document.
+------------------------+--------+---------------+---------------+ +------------------------+--------+---------------+---------------+
| Name | Code | Initial Value | Specification | | Name | Code | Initial Value | Specification |
+------------------------+--------+---------------+---------------+ +------------------------+--------+---------------+---------------+
| ENABLE_EX_HEADERS | 0xfbfb | 0 | | | ENABLE_XHEADERS | 0xfbfb | 0 | |
+------------------------+--------+---------------+---------------+ +------------------------+--------+---------------+---------------+
5.3. Error Code Registry 5.3. Error Code Registry
The entry in the following table are registered by this document. The entry in the following table are registered by this document.
+----------------------+------+-------------------+---------------+ +----------------------+------+-------------------+---------------+
| Name | Code | Description | Specification | | Name | Code | Description | Specification |
+----------------------+------+-------------------+---------------+ +----------------------+------+-------------------+---------------+
| ROUTING_STREAM_ERROR | 0xfb | Routing stream is | | | ROUTING_STREAM_ERROR | 0xfb | Routing stream is | |
| | | not open | | | | | not open | |
| EX_HEADERS_NOT_ | 0xfc | EX_HEADERS is not | | | XHEADERS_NOT_ | 0xfc | XHEADERS is not | |
| ENABLED_ERROR | | enabled yet | | | ENABLED_ERROR | | enabled yet | |
+----------------------+------+-------------------+---------------+ +----------------------+------+-------------------+---------------+
6. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202,
DOI 10.17487/RFC6202, April 2011,
<https://www.rfc-editor.org/info/rfc6202>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/info/rfc8441>.
Authors' Addresses Authors' Addresses
Guowu Xie Guowu Xie
Facebook Inc. Facebook Inc.
1 Hacker Way
Menlo Park
Email: woo@fb.com Email: woo@fb.com
Alan Frindell Alan Frindell
Facebook Inc. Facebook Inc.
Email: afrind@fb.com Email: afrind@fb.com
 End of changes. 52 change blocks. 
155 lines changed or deleted 312 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/