An HTTP/2 Extension for Bidirectional Message Communication
draft-xie-bidirectional-messaging-02

Document Type Active Internet-Draft (individual)
Last updated 2019-07-08
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
httpbis Working Group                                             G. Xie
Internet-Draft                                               A. Frindell
Intended status: Standards Track                           Facebook Inc.
Expires: January 9, 2020                                   July 08, 2019

      An HTTP/2 Extension for Bidirectional Message Communication
                  draft-xie-bidirectional-messaging-02

Abstract

   This draft proposes an HTTP/2 protocol extension that enables
   bidirectional messaging communication between client and server.

Status of This Memo

   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 January 9, 2020.

Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Xie & Frindell           Expires January 9, 2020                [Page 1]
Internet-Draft                 HTTP-PUBSUB                     July 2019

1.  Introduction

   HTTP/2 [RFC7540] transports HTTP messages via a framing layer that
   includes many technologies and optimizations designed to make
   communication more efficient between clients and servers.  These
   include multiplexing of multiple streams on a single underlying
   transport connection, flow control, stream dependencies and
   priorities, header compression, and exchange of configuration
   information between endpoints.

   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.

   Currently, the only mechanism in HTTP/2 for server to client
   communication is server push.  That is, servers can initiate
   unidirectional push promised streams to clients, but clients cannot
   respond to them and either accept or discard them silently.
   Additionally, intermediaries along the path may have different server
   push policies and may not forward push promised streams to the
   downstream client.  This best effort mechanism is not sufficient to
   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.

   Several techniques have been developed to workaround these
   limitations: long polling [RFC6202], WebSocket [RFC8441], and
   tunneling using the CONNECT method.  All of these approaches layer an
   application protocol on top of HTTP/2, using HTTP/2 streams as
   transport connections.  This layering defeats the optimizations
   provided by HTTP/2.  For example, multiplexing multiple parallel
   interactions onto one HTTP/2 stream reintroduces head of line
   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.

Xie & Frindell           Expires January 9, 2020                [Page 2]
Internet-Draft                 HTTP-PUBSUB                     July 2019
Show full document text