< draft-xie-bidirectional-messaging-00.txt   draft-xie-bidirectional-messaging-01.txt >
httpbis Working Group G. Xie httpbis Working Group G. Xie
Internet-Draft F. Frindell Internet-Draft F. Frindell
Intended status: Standards Track Facebook Inc. Intended status: Standards Track Facebook Inc.
Expires: September 25, 2019 March 24, 2019 Expires: 6 October 2019 4 April 2019
An HTTP/2 extension for bidirectional messaging communication An HTTP/2 extension for bidirectional messaging communication
draft-xie-bidirectional-messaging-00 draft-xie-bidirectional-messaging-01
Abstract Abstract
This draft proposes a http2 protocol extension, which enables This draft proposes a http2 protocol extension, which 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.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 September 25, 2019. This Internet-Draft will expire on 6 October 2019.
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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
1. Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Routing Stream and ExStream . . . . . . . . . . . . . . 3
3.2. Bidirectional Messaging Communication . . . . . . . . . 3
3.3. States of RStream and ExStream . . . . . . . . . . . . 4
3.4. Negotiate the Extension through SETTINGS frame . . . . 5
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
HTTP/2 is the de facto application protocol in Internet. The HTTP/2 is the de facto application protocol in Internet. The
optimizations developed in HTTP/2, like stream multiplexing, header optimizations developed in HTTP/2, like stream multiplexing, header
compression, and binary message framing are very generic. They can compression, and binary message framing are very generic. They can
be useful in non web browsing applications, for example, Publish/ be useful in non web browsing applications, for example, Publish/
Subscribe, RPC. However, the request/response from client to server Subscribe, RPC. However, the request/response from client to server
communication pattern limits HTTP/2 from wider use in these communication pattern limits HTTP/2 from wider use in these
applications. This draft proposes a HTTP/2 protocol extension, which applications. This draft proposes a HTTP/2 protocol extension, which
enables bidirectional messaging between client and server. enables bidirectional messaging between client and server.
The only mechanism HTTP/2 provides for server to client communication The only mechanism HTTP/2 provides for server to client communication
is PUSH is PUSH_PROMISE. While this satisfies some use-cases, it is
unidirectional, i.g. the client cannot respond. In this draft, a new
PROMISE and the bi-directionality of HEADERS. Further, clients are frame is introduced which has the routing properties of PUSH_PROMISE
also able group streams together for routing purposes, such that each and the bi-directionality of HEADERS. Further, clients are also able
group streams together for routing purposes, such that each
individual stream does not need to carry additional routing individual stream does not need to carry additional routing
information. information.
2. 2. Conventions and Terminology
The keywords
,
,
,
,
,
,
,
,
, and
, when they appear in this document, are to be interpreted as The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
described in [RFC2119]. SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when 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. 3. Solution Overview
3.1. 3.1. Routing Stream and ExStream
A routing stream (RStream) is a long lived HTTP/2 stream in nature. A routing stream (RStream) is a long lived HTTP/2 stream in nature.
RStreams are initiated by clients, and can be routed independently by RStreams are initiated by clients, and can be routed independently by
any intermediaries. Though an RStream is effectively a regular any intermediaries. Though an RStream is effectively a regular
HTTP/2 stream, RStreams are recommended for exchanging metadata, but HTTP/2 stream, RStreams are recommended for exchanging metadata, but
not user data. not user data.
A new HTTP/2 stream called ExStream is introduced for exchanging user A new HTTP/2 stream called ExStream is introduced for exchanging user
data. ExStreams are recommended for short lived transactions, so data. ExStreams are recommended for short lived transactions, so
intermediaries and servers can gracefully shutdown ExStreams within a intermediaries and servers can gracefully shutdown ExStreams within a
short time. The typical use case can be a subscription or publish short time. The typical use case can be a subscription or publish
request/response in Publish/Subscribe use case, or an RPC call request/response in Publish/Subscribe use case, or an RPC call
between two endpoints. between two endpoints.
An ExStream is opened by an EX_HEADERS frame, and continued by An ExStream is opened by an EX_HEADERS frame, and continued by
CONTINUATION and DATA frames. An ExStream CONTINUATION and DATA frames. An ExStream MUST be associated with an
open RStream, and MUST NOT be associated with any other ExStream.
be associated with an open RStream, and ExStreams are routed according to their RStreams by intermediaries
and servers. Effectively, all ExStreams with the same RStream form a
be associated with any other ExStream. ExStreams are routed logical stream group, and are routed to the same endpoint.
according to their RStreams by intermediaries and servers.
Effectively, all ExStreams with the same RStream form a logical
stream group, and are routed to the same endpoint.
3.2. 3.2. Bidirectional Messaging Communication
With RStreams and ExStreams, HTTP/2 can be used for bidirectional With RStreams and ExStreams, HTTP/2 can be used for bidirectional
messaging communication. As shown in the follow diagrams, after an messaging communication. As shown in the follow diagrams, after an
RStream is open from client to server, either endpoint can initiate RStream is open from client to server, either endpoint can initiate
an ExStreams to its peer. an ExStreams 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) | | ExStream(7, RS=5) | | ExStream(3, RS=1) |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Figure 1 Figure 1: Client initiates the ExStream to server, after an
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) | | ExStream(4, RS=5) | | ExStream(2, RS=1) |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Figure 2: Server initiates the ExStream to client, after an
Figure 2 RStream is open.
Beyond that, clients can multiplex RStreams, ExStreams and regular Beyond that, clients can multiplex RStreams, ExStreams and regular
HTTP/2 streams into one HTTP/2 connection. This enables clients to HTTP/2 streams into one HTTP/2 connection. This enables clients to
access different services without initiating new TCP connections. access different services without initiating new TCP connections.
This avoids the latency cost of setting up new connections. This is This avoids the latency cost of setting up new connections. This is
more desirable for mobile devices because they usually have longer more desirable for mobile devices because they usually have longer
RTT and battery constraints. Multiplexing these services also allows RTT and battery constraints. Multiplexing these services also allows
them to share a single TCP connection congestion control context. them to share a single TCP connection congestion control context.
As shown in the following diagram, the client can exchange data with As shown in the following diagram, the client can exchange data with
skipping to change at page 4, line 37 skipping to change at page 4, line 30
+--------+ +---------+ +----------+ +--------+ +---------+ +----------+
v v ^ ^ v v v v ^ ^ v v
| | RStream (7) / | | \ RStream (5) +----------+ | | RStream (7) / | | \ RStream (5) +----------+
| +-------------------+ | | +---------------->| RPC | | +-------------------+ | | +---------------->| RPC |
| | | +----------+ | | | +----------+
| | | | | |
| Stream (9) | | Stream (7) +----------+ | Stream (9) | | Stream (7) +----------+
+---------------------------+ +--------------------->| CDN | +---------------------------+ +--------------------->| CDN |
+----------+ +----------+
Figure 3 Figure 3: Client opens multiple RStreams and a HTTP/2 stream
within one HTTP/2 connection.
3.3. 3.3. States of RStream and ExStream
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 in [RFC7540], section 5.1. ExStreams use the same lifecycle as
regular HTTP/2 streams, but also depend on their RStreams. If a regular HTTP/2 streams, but also depend on their RStreams. If a
RStream is reset, endpoints RStream is reset, endpoints MUST reset the ExStreams associated with
that RStream. If the RStream is closed, endpoints SHOULD allow
reset the ExStreams associated with that RStream. If the RStream is existing ExStreams complete normally. The RStream SHOULD remain open
closed, endpoints SHOULD allow existing ExStreams 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 timeouts on the RStream while associated
ExStreams are open.
A sender A sender MUST NOT initiate new ExStreams if on an RStream that is in
initiate new ExStreams if on an RStream that is in the open or half the open or half closed (remote) state.
closed (remote) state.
Endpoints process new ExStreams only when the RStream is open or half Endpoints process new ExStreams only when the RStream is open or half
closed (local) state. If an endpoint receives an EX closed (local) state. If an endpoint receives an EX_HEADERS frame
specifying an RStream in the closed or haf closed (remote) state, it
STREAM_ERROR. MUST respond with a connection error of type ROUTING_STREAM_ERROR.
3.4. 3.4. Negotiate the Extension through SETTINGS frame
The extension SHOULD be disabled by default. Endpoints can negotiate The extension SHOULD be disabled by default. Endpoints can negotiate
the use of the extension through the SETTINGS frame. If an the use of the extension through the SETTINGS frame. If an
implementation supports the extension, it is RECOMMENDED to include implementation supports the extension, it is RECOMMENDED to include
the ENABLE the ENABLE_EX_HEADERS setting in the initial SETTINGS frame. HTTP/2
compliant implementations will ignore the setting if it is unknown.
HEADERS setting in the initial SETTINGS frame. HTTP/2 compliant An endpoint can send EX_HEADERS frames immediately upon receiving a
implementations will ignore the setting if it is unknown. An SETTINGS frame with ENABLE_EX_HEADERS=1.
endpoint can send EX
EX_HEADERS=1.
Endpoints MUST NOT send out EX
EX
HEADERS will be ignored, making the header compression contexts
inconsistent between sender and receiver.
If an endpoint supports this extension, but receives EX
EX
HEADER
ENABLED_ERROR.
Intermediaries SHOULD send the ENABLE
HEADERS setting to clients, only if intermediaries and their upstream Endpoints MUST NOT send out EX_HEADERS before receiving a SETTINGS
servers can support this extension. If an intermediary receives an frame with the ENABLE_EX_HEADERS=1. If a remote endpoint does not
ExStream but discovers the destination endpoint does not support the support this extension, the EX_HEADERS will be ignored, making the
extension, it MUST reset the stream with EX header compression contexts inconsistent between sender and receiver.
NOT If an endpoint supports this extension, but receives EX_HEADERS
before ENABLE_EX_HEADERS, it MUST respond with a connection error
EX_HEADER_NOT_ENABLED_ERROR.
ERROR. Intermediaries SHOULD send the ENABLE_EX_HEADERS setting to clients,
only if intermediaries and their upstream servers can support this
extension. If an intermediary receives an ExStream but discovers the
destination endpoint does not support the extension, it MUST reset
the stream with EX_HEADER_NOT_ENABLED_ERROR.
3.5. 3.5. Interaction with standard http2 features
The extension implementation should apply stream and connection level The extension implementation should apply stream and connection level
flow control, maximum concurrent streams limit, GOAWAY logic to both flow control, maximum concurrent streams limit, GOAWAY logic to both
RStreams and ExStreams. RStreams and ExStreams.
4. 4. HTTP2 EX_HEADERS Frame
The EX
HEADERS has one extra field, RStream ID. It is used to open an The EX_HEADERS frame (type=0xfb) has all the fields and frame header
flags defined by HEADERS frame in HEADERS [RFC7540]. Moreover,
EX_HEADERS has one extra field, RStream ID. It is used to open an
ExStream, and additionally carries a header block fragment. ExStream, and additionally carries a header block fragment.
EX_HEADERS frames can be sent on a stream in the "idle", "open", or EX_HEADERS frames can be sent on a stream in the "idle", "open", or
"half-closed (remote)" state. "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 EX_HEADERS frame.
+---------------+ +---------------+
|Pad Length? (8)| |Pad Length? (8)|
skipping to change at page 6, line 38 skipping to change at page 6, line 19
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
| Weight? (8) | | Weight? (8) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
|R| Routing Stream ID (31) | |R| Routing Stream ID (31) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
| Header Block Fragment (*) ... | Header Block Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Padding (*) ... | Padding (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 4 Figure 4: EX_HEADERS Frame Payload
The RStream specified in EX
STREAM
ERROR, if the specified RStream is missing; or is an ExStream rather The RStream specified in EX_HEADERS frames MUST be an open stream.
than a stream; or is closed or half-closed (remote). Otherwise, the The recipient MUST respond with a connection error
states maintained for header compression or flow control) may be out ROUTING_STREAM_ERROR PROTOCOL_ERROR, if the specified RStream is
of sync. missing; or is an ExStream rather than a stream; or is closed or
half-closed (remote). Otherwise, the states maintained for header
compression or flow control) may be out of sync.
5. 5. IANA Considerations
This document establishes a registry for a new frame type, setting, This document establishes a registry for a new frame type, setting,
and error code. and error code.
5.1. 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.
5.2. +---------------+------+--------------+
| Frame Type | Code | Section |
+---------------+------+--------------+
| EX_HEADERS | 0xfb | |
+---------------+------+--------------+
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.
5.3. +------------------------+--------+---------------+---------------+
| Name | Code | Initial Value | Specification |
+------------------------+--------+---------------+---------------+
| ENABLE_EX_HEADERS | 0xfbfb | 0 | |
+------------------------+--------+---------------+---------------+
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.
6. References +----------------------+------+-------------------+---------------+
| Name | Code | Description | Specification |
+----------------------+------+-------------------+---------------+
| ROUTING_STREAM_ERROR | 0xfb | Routing stream is | |
| | | not open | |
| EX_HEADERS_NOT_ | 0xfc | EX_HEADERS is not | |
| ENABLED_ERROR | | enabled yet | |
+----------------------+------+-------------------+---------------+
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
Authors' Addresses Authors' Addresses
Guowu Xie Guowu Xie
Facebook Inc. Facebook Inc.
1 Hacker Way 1 Hacker Way
Menlo Park CA 94025 Menlo Park
U.S.A.
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. 35 change blocks. 
120 lines changed or deleted 129 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/