idnits 2.17.1 draft-montenegro-httpbis-http2-negotiation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4183 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 151, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 154, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-21 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Tarreau 3 Internet-Draft Exceliance 4 Expires: April 18, 2013 G. Montenegro 5 Microsoft 6 October 15, 2012 8 HTTP 2.0 Negotiation 9 draft-montenegro-httpbis-http2-negotiation-00 11 Abstract 13 This document describes an Upgrade-based protocol negotiation 14 proposal for HTTP 2.0. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 18, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Optimizing the Handshake . . . . . . . . . . . . . . . . . . . 5 53 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 56 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 59 1. Introduction 61 HTTP/2.0 will have the capability (but not the requirement) to use 62 the same ports as HTTP/1.X, typically, but not limited to, 80 (in the 63 clear) and 443 (when over TLS/SSL). Of course, it is possible for a 64 client to somehow acquire knowledge that a server implements HTTP/2.0 65 at a given port. In such a case, the client can immediately begin 66 sending HTTP/2.0 binary frames to the server, and the server can 67 immediately respond with the corresponding HTTP/2.0 frames. How that 68 knowledge is acquired is not the subject of this note. It could be 69 acquired by some out-of-band means such as using the DNS/DANE, or by 70 some configuration prior to the HTTP/2.0 exchange. Or it could have 71 been aquired earlier in-band in an earlier exchange. It could have 72 been acquired at an earlier phase of this same exchange, for example, 73 via TLS-NPN. 75 Nevertheless, there may be some situations, in which the client can 76 only assume that a server speaks HTTP/1.X. In such cases, a 77 connection upgrade mechanism to opportunistically attempt to HTTP/2.0 78 is essential. Otherwise, the exchange will remain at HTTP/1.X 79 despite both client and server being able to speak HTTP/2.0. 81 This document specifies such a connection upgrade for HTTP/2.0. This 82 handshake does not incur any extra delay in obtaining a response in 83 HTTP/2.0, as the protocol switch is immediate and effective within 84 the first round trip. There is no delay either if there is no 85 protocol switch, as the server is capable to respond via HTTP/1.1 86 also within the first initial round trip. 88 This handshake uses the Upgrade header defined in HTTP/1.1 89 [I-D.ietf-httpbis-p1-messaging]. This Upgrade header is also in wide 90 use by the WebSocket protocol for similar purposes [RFC6455]. 92 The goal of this document is to propose additional text to the 93 HTTP/2.0 specification. The starting point for HTTP/2.0, the SPDY 94 [I-D.mbelshe-httpbis-spdy] protocol, has no language with respect to 95 a connection upgrade procedure. Hence, the text below could be 96 incorporated as a new section or sections within the HTTP/2.0 97 document. 99 2. Negotiation 101 If a client has no knowledge about a server's support for HTTP/2.0, 102 it starts with HTTP/1.1 and attempt an upgrade to HTTP/2.0 as 103 follows: 105 GET /default.htm HTTP/1.1 106 Host: server.example.com 107 Connection: Upgrade 108 Upgrade: HTTP/2.0 110 If the server does not support the new protocol, it will simply 111 respond to the client using HTTP/1.1: 113 HTTP/1.1 200 OK 114 Content-length: 243 115 Content-type: text/html 116 ... 118 If the server switches to the new protocol, it will signal so via a 119 101 response. The server switches to HTTP/2.0 immediately after the 120 empty line which terminates the 101 response 121 [I-D.ietf-httpbis-p2-semantics]. 123 HTTP/1.1 101 Switching Protocols 124 Connection: Upgrade 125 Upgrade: HTTP/2.0 127 [ HTTP/2.0 frame ] 129 3. Optimizing the Handshake 131 This handshake may be further optimized by the definition of HTTP 132 headers of the form "HTTP2-header_name". These "HTTP2" headers would 133 be meant to be interpreted exclusively by HTTP/2.0 servers and 134 applied upon a successful Upgrade to further optimize or proactively 135 configure the subsequent HTTP/2.0 exchanges. These headers would be 136 ignored by HTTP/1.1 servers. The HTTP2 headers are for future 137 revisions of this document. 139 4. Acknowledgements 141 This document incorporates material from 142 [I-D.tarreau-httpbis-network-friendly] and 143 [I-D.montenegro-httpbis-speed-mobility]. 145 This document was produced using the xml2rfc tool [RFC2629]. 147 5. References 149 5.1. Normative References 151 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 152 Requirement Levels", BCP 14, RFC 2119, March 1997. 154 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 155 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 156 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 158 [I-D.ietf-httpbis-p1-messaging] 159 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 160 (HTTP/1.1): Message Syntax and Routing", 161 draft-ietf-httpbis-p1-messaging-21 (work in progress), 162 October 2012. 164 [I-D.ietf-httpbis-p2-semantics] 165 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 166 (HTTP/1.1): Semantics and Content", 167 draft-ietf-httpbis-p2-semantics-21 (work in progress), 168 October 2012. 170 5.2. Informative References 172 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 173 June 1999. 175 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 176 RFC 6455, December 2011. 178 [I-D.mbelshe-httpbis-spdy] 179 Belshe, M. and R. Peon, "SPDY Protocol", 180 draft-mbelshe-httpbis-spdy-00 (work in progress), 181 February 2012. 183 [I-D.montenegro-httpbis-speed-mobility] 184 Trace, R., Foresti, A., Singhal, S., Mazahir, O., Nielsen, 185 H., Raymor, B., Rao, R., and G. Montenegro, "HTTP Speed+ 186 Mobility", draft-montenegro-httpbis-speed-mobility-02 187 (work in progress), June 2012. 189 [I-D.tarreau-httpbis-network-friendly] 190 Tarreau, W., Jeffries, A., and A. Croy, "Proposal for a 191 Network-Friendly HTTP Upgrade", 192 draft-tarreau-httpbis-network-friendly-00 (work in 193 progress), March 2012. 195 Authors' Addresses 197 Willy Tarreau 198 Exceliance 200 Email: w@1wt.eu 202 Gabriel Montenegro 203 Microsoft 205 Email: Gabriel.Montenegro@microsoft.com