idnits 2.17.1 draft-montenegro-httpbis-http2-negotiation-01.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 (January 16, 2013) is 4080 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 183, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 186, 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) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-00 Summary: 3 errors (**), 0 flaws (~~), 7 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: July 20, 2013 E. Stephan 5 Orange 6 G. Montenegro 7 Microsoft 8 January 16, 2013 10 HTTP 2.0 Negotiation 11 draft-montenegro-httpbis-http2-negotiation-01 13 Abstract 15 This document describes an Upgrade-based protocol negotiation 16 proposal for HTTP 2.0. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 20, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Optimizing the Handshake . . . . . . . . . . . . . . . . . . . 5 55 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 62 1. Introduction 64 User agents interact with numerous servers from different domains 65 using different versions of HTTP. In particular, the co-existence of 66 HTTP/1.x and HTTP/2.x requires a protocol negotiation mechanism 67 transparent to the user agents. This document specifies an Upgrade- 68 based HTTP 2.0 connection negotiation. 70 HTTP/2.0 will have the capability (but not the requirement) to use 71 the same ports as HTTP/1.X, typically, but not limited to, 80 (in the 72 clear) and 443 (when over TLS/SSL). Of course, it is possible for a 73 client to somehow acquire knowledge that a server implements HTTP/2.0 74 at a given port. In such a case, the client can immediately begin 75 sending HTTP/2.0 binary frames to the server, and the server can 76 immediately respond with the corresponding HTTP/2.0 frames. How that 77 knowledge is acquired is not the subject of this note. It could be 78 acquired by some out-of-band means such as using the DNS, or by some 79 configuration prior to the HTTP/2.0 exchange. Or it could have been 80 aquired earlier in-band in a previous exchange using, for example, 81 the Upgrade-based mechanism specified in this document. It could 82 have also been acquired at an earlier phase of this same exchange, 83 for example, at a lower protocol layer that precedes the overall HTTP 84 sequence, such as in the TLS handshake (if using TLS). 86 Nevertheless, there may be some situations, in which the client can 87 only assume that a server speaks HTTP/1.X. In such cases, a 88 connection upgrade mechanism to opportunistically attempt switching 89 to HTTP/2.0 is essential. Otherwise, the exchange will remain at 90 HTTP/1.X despite both client and server being willing to speak 91 HTTP/2.0. 93 This document specifies such a connection upgrade for HTTP/2.0. This 94 handshake does not incur any extra delay in obtaining a response in 95 HTTP/2.0, as the protocol switch is immediate and effective within 96 the first round trip. There is no delay either if there is no 97 protocol switch, as the server is capable to respond via HTTP/1.1 98 also within the first initial round trip. 100 This handshake uses the Upgrade header defined in HTTP/1.1 101 [I-D.ietf-httpbis-p1-messaging]. This Upgrade header is also in wide 102 use by the WebSocket protocol for similar purposes [RFC6455]. 104 The goal of this document is to propose additional text to the 105 HTTP/2.0 specification. The starting point for HTTP/2.0, the initial 106 version of [I-D.ietf-httpbis-http2], has no language with respect to 107 a connection upgrade procedure. Hence, the text below could be 108 incorporated as a new section or sections within the HTTP/2.0 109 document. 111 2. Negotiation 113 If a client has no knowledge about a server's support for HTTP/2.0, 114 it starts with HTTP/1.1 and attempt an upgrade to HTTP/2.0 as 115 follows: 117 GET /default.htm HTTP/1.1 118 Host: server.example.com 119 Connection: Upgrade 120 Upgrade: HTTP/2.0 122 If the server does not support the new protocol, it will simply 123 respond to the client using HTTP/1.1: 125 HTTP/1.1 200 OK 126 Content-length: 243 127 Content-type: text/html 128 ... 130 If the server switches to the new protocol, it will signal so via a 131 101 response. The server switches to HTTP/2.0 immediately after the 132 empty line which terminates the 101 response 133 [I-D.ietf-httpbis-p2-semantics]. 135 HTTP/1.1 101 Switching Protocols 136 Connection: Upgrade 137 Upgrade: HTTP/2.0 139 [ HTTP/2.0 frame ] 141 In the above, the string "HTTP/2.0" represents the final version of 142 the protocol defined in [I-D.ietf-httpbis-http2]. However, per 143 guidance in that document, preliminary revisions of that document 144 (either draft or experimental) are denoted by adding the 145 corresponding version or revision number. For example, if the above 146 handshake were negotiating the use of the 03 version of the draft 147 (draft-ietf-httpbis-http2-03), then, instead of using "HTTP/2.0" 148 above, the handshake would use "HTTP-03/2.0" instead. 150 3. Optimizing the Handshake 152 This handshake may be further optimized by the definition of HTTP 153 headers of the form "HTTP2-header_name". These "HTTP2" headers would 154 be meant to be interpreted exclusively by HTTP/2.0 servers and 155 applied upon a successful Upgrade to further optimize or proactively 156 configure the subsequent HTTP/2.0 exchanges. These headers would be 157 ignored by HTTP/1.1 servers. The HTTP2 headers are for future 158 revisions of this document. 160 4. Acknowledgements 162 This document incorporates material from 163 [I-D.tarreau-httpbis-network-friendly] and 164 [I-D.montenegro-httpbis-speed-mobility]. 166 This document was produced using the xml2rfc tool [RFC2629]. 168 5. Appendix 170 This Upgrade-based handshake may have issues with certain proxies and 171 intermediaries, particularly those that are not aware of its use and 172 don't obey its semantics. Some heuristics that have been observed to 173 help in this respect is to turn off caching by adding the following 174 to the client request: 176 Pragma: no-cache 177 Cache-Control: no-cache 179 6. References 181 6.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, March 1997. 186 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 187 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 188 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 190 [I-D.ietf-httpbis-p1-messaging] 191 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 192 (HTTP/1.1): Message Syntax and Routing", 193 draft-ietf-httpbis-p1-messaging-21 (work in progress), 194 October 2012. 196 [I-D.ietf-httpbis-p2-semantics] 197 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 198 (HTTP/1.1): Semantics and Content", 199 draft-ietf-httpbis-p2-semantics-21 (work in progress), 200 October 2012. 202 6.2. Informative References 204 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 205 June 1999. 207 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 208 RFC 6455, December 2011. 210 [I-D.ietf-httpbis-http2] 211 Belshe, M., Peon, R., Thomson, M., and A. Melnikov, "SPDY 212 Protocol", draft-ietf-httpbis-http2-00 (work in progress), 213 November 2012. 215 [I-D.montenegro-httpbis-speed-mobility] 216 Trace, R., Foresti, A., Singhal, S., Mazahir, O., Nielsen, 217 H., Raymor, B., Rao, R., and G. Montenegro, "HTTP Speed+ 218 Mobility", draft-montenegro-httpbis-speed-mobility-02 219 (work in progress), June 2012. 221 [I-D.tarreau-httpbis-network-friendly] 222 Tarreau, W., Jeffries, A., and A. Croy, "Proposal for a 223 Network-Friendly HTTP Upgrade", 224 draft-tarreau-httpbis-network-friendly-00 (work in 225 progress), March 2012. 227 Authors' Addresses 229 Willy Tarreau 230 Exceliance 232 Email: w@1wt.eu 234 Emile Stephan 235 Orange 237 Email: emile.stephan@orange.com 239 Gabriel Montenegro 240 Microsoft 242 Email: Gabriel.Montenegro@microsoft.com