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]
