Internet DRAFT - draft-zhu-httpbis-http2-protocol-layering

draft-zhu-httpbis-http2-protocol-layering



 



HTTPbis Working Group                                             W. Zhu
INTERNET-DRAFT                                                T. Yoshino
Intended Status: Informational                                   R. Peon
Expires: September 4, 2014                                  Google, Inc.
                                                           March 3, 2014


                      Protocol Layering in HTTP/2 
            draft-zhu-httpbis-http2-protocol-layering-00.txt


Abstract

   This document discusses requirements that will allow HTTP/2 to be
   used as a generic transport for use cases beyond the basic HTTP/1.1
   request-response messaging.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2014 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
   (http://trustee.ietf.org/license-info) in effect on the date of
 


Zhu, et al.            Expires September 4, 2014                [Page 1]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


   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.










































 


Zhu, et al.            Expires September 4, 2014                [Page 2]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


Table of Contents

   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
   2  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      3.1  Message Boundary  . . . . . . . . . . . . . . . . . . . . . 4
      3.2  Scheme Header . . . . . . . . . . . . . . . . . . . . . . . 4
      3.3  Load Balancers  . . . . . . . . . . . . . . . . . . . . . . 5
      3.4  Protocol Layering . . . . . . . . . . . . . . . . . . . . . 5
   4  Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   5  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
   6  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
   7  References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
      7.1  Normative References  . . . . . . . . . . . . . . . . . . . 7
      7.2  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8































 


Zhu, et al.            Expires September 4, 2014                [Page 3]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


1  Introduction

   This document discusses requirements that will allow HTTP/2 [I-
   D.ietf-httpbis-http2] to be used as a generic transport for use cases
   beyond the basic HTTP/1.1 [I-D.ietf-httpbis-p2-semantics] request-
   response messaging.


1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2  Use Cases

   Specifically we have the following use cases in mind:

   1. Map HTML5 WebSocket API [WSAPI] to HTTP/2 directly.

   2. Map non-XHR [XHR] APIs, for example HTML5 Server-Sent Events
      [ServerSent] to HTTP/2 without requiring additional layers of
      framing within the HTTP payload.

   3. Map non-browser, bidirectional messaging protocols such as XMPP
      [RFC6120] or future cloud protocols to HTTP/2 to benefit from the
      ubiquitous infrastructure support of HTTP.

3  Requirements

3.1  Message Boundary

   To enable the above use cases, the DATA frames of HTTP/2 SHOULD
   include a flag to mark the message boundary, for example END_SEGMENT
   as defined in [I-D.ietf-httpbis-http2].

   This boundary SHOULD be preserved by any proxy that understands
   HTTP/2.

   For HTTP/1.1 gateways, we expect the message boundary will be
   preserved as chunked Transfer-Encoding.  T-E however is a hop-by-hop
   property and downstream proxies may still break the message boundary
   by re-chunking the request or response payload.  Since it's likely
   that the server will only speak HTTP/1.1, and therefore the client
   API mapping is expected to fall-back to HTTP/1.1.

3.2  Scheme Header
 


Zhu, et al.            Expires September 4, 2014                [Page 4]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


   The initial HEADERS frame for a new stream SHOULD include the URL
   scheme to indicate the scheme as understood by client or server
   applications, e.g. "http", "ws", "xmpp".

   A new HTTP/2 error status code SHOULD be introduced to indicate that
   a given scheme is not supported by the server, e.g.
   "SCHEME_NOT_SUPPORTED", "SCHEME_NOT_SUPPORTED_BY_PROXY".

   Whether or not the scheme is "http", a new HTTP error code MAY be
   defined to inform the HTTP/2 capable client with an optional payload
   that the origin server does not support the given scheme.

3.3  Load Balancers

   These requirements enable L7 load balancers to mux or demux and
   perform other load balancing based on a simple examination of scheme,
   host, and port.

3.4  Protocol Layering

   We don't expect any ALPN identifier to be used for these non-HTTP
   protocols. This allows us to layer any non-HTTP protocol on top of
   HTTP/2 without requiring changes to the infrastructure created for
   HTTP/2.
























 


Zhu, et al.            Expires September 4, 2014                [Page 5]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


4  Security Considerations

   TBA


5  IANA Considerations

   None.


6  Acknowledgments

   We would like to thank Mark Nottingham for his inputs and helpful
   discussion.


































 


Zhu, et al.            Expires September 4, 2014                [Page 6]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


7  References

7.1  Normative References

   [RFC6120]   Saint-Andre, P., "Extensible Messaging and Presence
               Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2  Informative References

   [I-D.ietf-httpbis-http2]   Belshe, M., Peon, R., Thomson, M., and A.
               Melnikov, "Hypertext Transfer Protocol version 2.0",
               draft-ietf-httpbis-http2-10 (work in progress), February
               2014.

   [I-D.ietf-httpbis-p2-semantics]   Fielding, R. and J. Reschke,
               "Hypertext Transfer Protocol (HTTP/1.1): Semantics and
               Content",          draft-ietf-httpbis-p2-semantics-26
               (work in progress), February 2014.

   [WSAPI]     Hickson, I., "The Web Sockets API", February 2014,
               <http://dev.w3.org/html5/websockets/>.

   [ServerSent] Hickson, I., "Server-Sent Events", February 2014,
               <http://dev.w3.org/html5/eventsource/>.

   [XHR]       Hickson, A., Hickson, J., Hickson, J., and H. Steen,
               "XMLHttpRequest", November 2013,
               <https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html>.

















 


Zhu, et al.            Expires September 4, 2014                [Page 7]

INTERNET DRAFT        Protocol Layering in HTTP/2          March 3, 2014


Author's Addresses

   Wenbo Zhu
   Google, Inc.

   Email: wenboz@google.com


   Takeshi Yoshino
   Google, Inc.

   Email: tyoshino@google.com


   Roberto Peon
   Google, Inc.

   Email: fenix@google.com

































Zhu, et al.            Expires September 4, 2014                [Page 8]