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, . [ServerSent] Hickson, I., "Server-Sent Events", February 2014, . [XHR] Hickson, A., Hickson, J., Hickson, J., and H. Steen, "XMLHttpRequest", November 2013, . 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]