idnits 2.17.1 draft-montenegro-httpbis-speed-mobility-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 15, 2012) is 4326 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 1308, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Possible downref: Normative reference to a draft: ref. 'I-D.mbelshe-httpbis-spdy' == Outdated reference: A later version (-17) exists of draft-iab-extension-recs-14 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Trace 3 Internet-Draft A. Foresti 4 Expires: December 17, 2012 S. Singhal 5 O. Mazahir 6 H. Nielsen 7 B. Raymor 8 R. Rao 9 G. Montenegro 10 Microsoft 11 June 15, 2012 13 HTTP Speed+Mobility 14 draft-montenegro-httpbis-speed-mobility-02 16 Abstract 18 This document describes "HTTP Speed+Mobility," a proposal for HTTP 19 2.0 that emphasizes performance improvements and security while at 20 the same time accounting for the important needs of mobile devices 21 and applications. The proposal starts from both the Google SPDY 22 protocol and the work the IETF has done around WebSockets. The 23 proposal is not a final product but rather is intended to form a 24 baseline for working group discussion. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 17, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1.1. Maintain existing HTTP semantics . . . . . . . . . . . 6 63 1.1.2. Layered Architecture . . . . . . . . . . . . . . . . . 6 64 1.1.3. Use of Existing standards . . . . . . . . . . . . . . 6 65 1.1.4. Client is in control of content . . . . . . . . . . . 7 66 1.1.5. Network Cost and Power . . . . . . . . . . . . . . . . 8 67 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 68 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10 69 1.3.1. Connection Management . . . . . . . . . . . . . . . . 12 70 1.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 3. Session layer and Framing . . . . . . . . . . . . . . . . . . 15 73 3.1. Opening and Closing Sessions . . . . . . . . . . . . . . . 15 74 3.2. Origin of Multiplexed Content . . . . . . . . . . . . . . 15 75 3.3. WebSocket Framing Protocol . . . . . . . . . . . . . . . . 16 76 3.4. Closing HTTP Speed+Mobility Sessions . . . . . . . . . . . 17 77 4. Streams Layer . . . . . . . . . . . . . . . . . . . . . . . . 18 78 4.1. Stream Management . . . . . . . . . . . . . . . . . . . . 18 79 4.1.1. Stream Creation . . . . . . . . . . . . . . . . . . . 18 80 4.1.2. Stream Data Exchange . . . . . . . . . . . . . . . . . 18 81 4.1.3. Stream Half-Close . . . . . . . . . . . . . . . . . . 19 82 4.1.4. Stream Close . . . . . . . . . . . . . . . . . . . . . 19 83 4.1.5. Error Handling . . . . . . . . . . . . . . . . . . . . 19 84 4.2. Stream Control Frames . . . . . . . . . . . . . . . . . . 20 85 4.2.1. SYN_STREAM . . . . . . . . . . . . . . . . . . . . . . 20 86 4.2.2. SYN_REPLY . . . . . . . . . . . . . . . . . . . . . . 21 87 4.2.3. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . 22 88 4.2.4. CREDIT_UPDATE . . . . . . . . . . . . . . . . . . . . 23 89 4.3. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 24 90 4.4. Name/Value Header Block . . . . . . . . . . . . . . . . . 24 91 4.5. Compression . . . . . . . . . . . . . . . . . . . . . . . 25 92 5. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 5.1. Stream Priority . . . . . . . . . . . . . . . . . . . . . 27 94 5.2. Credit Control . . . . . . . . . . . . . . . . . . . . . . 27 95 5.3. Credit Control Declaration . . . . . . . . . . . . . . . . 27 96 5.4. Credit Balance Updates . . . . . . . . . . . . . . . . . . 28 97 5.5. Turning Credit Control Off for a Stream . . . . . . . . . 29 98 5.6. Increasing and Decreasing Stream Credit . . . . . . . . . 29 99 5.7. Implementation Guidance and Considerations . . . . . . . . 29 100 6. General Notes . . . . . . . . . . . . . . . . . . . . . . . . 31 101 6.1. HTTP Layering . . . . . . . . . . . . . . . . . . . . . . 31 102 6.2. Relationship to SPDY . . . . . . . . . . . . . . . . . . . 31 103 6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 31 104 6.4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 31 105 6.4.1. Flow Control . . . . . . . . . . . . . . . . . . . . . 32 106 6.4.2. Streams Issues . . . . . . . . . . . . . . . . . . . . 32 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 109 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 110 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 113 1. Introduction 115 Over the course of its almost two decades of existence, the HTTP 116 protocol has enabled the web to experience phenomenal growth and 117 change the world in more ways than its creators might have imagined. 118 HTTP's designers got many design principles right, including 119 simplicity and robustness. These characteristics allow billions of 120 devices to support and use HTTP in a multitude of communication 121 scenarios. However, it is time to improve upon HTTP 1.1. 123 Improving HTTP starts with speed. Web sites have become complex. A 124 single site could comprise hundreds of different elements (from 125 images to videos to ads to news feeds and so on) that need to get 126 retrieved by the client before the page can be fully displayed. 127 Users expect all of this to happen securely and instantly across all 128 their devices and applications. In many scenarios, HTTP fails to 129 meet these expectations. Speed improvements need to apply not only 130 for browsers but also for apps. More and more, apps are how people 131 access web services, in addition to their browser. A key attribute 132 of mobile applications is that they may access only a subset of the 133 web site's data, relying on local application logic to process the 134 data and create a presentation and interaction layer. 136 The design of HTTP--how every application and service on the web 137 communicates today--can positively impact user experience, 138 operational and environmental costs, and even the battery life of the 139 devices you carry around. Improving HTTP should also ensure great 140 battery life and low network cost on constrained devices. People and 141 their apps should stay in control of network access. Finally, to 142 achieve rapid adoption, HTTP 2.0 needs to retain as much 143 compatibility as possible with the existing Web infrastructure. Done 144 right, HTTP 2.0 can help people connect their devices and 145 applications to the Internet fast, reliably, and securely over a 146 number of diverse networks, with great battery life and low cost. 148 At the core of the speed problem is that HTTP does not allow for out- 149 of-order or interleaved responses. This requires the establishment 150 of multiple TCP connections for concurrency (pipelining is formally 151 supported by the protocol but is seldom implemented in practice). 152 The overhead in terms of additional round trips and dealing with TCP 153 slow start causes a significant performance penalty. This leads to a 154 variety of issues, such as additional round trips for connection 155 setup, slow-start delays, and potentially connection rationing: the 156 client may not be able to dedicate many connections to any single 157 server, and the server needs to protect itself from denial-of-service 158 attacks. As a result, users are often disappointed in the perceived 159 performance of websites. 161 Improving HTTP should also make mobile apps and devices better. When 162 HTTP was first developed, mobile communication was virtually non- 163 existent, but today the mobile Web is an integral and fast-growing 164 part of the Web. The different conditions on mobile communications 165 require rethinking of how protocols work. For example, people want 166 their mobile devices to have better battery life. HTTP 2.0 can help 167 decrease the power consumption of network access. Mobile devices 168 also give people a choice of networks with different costs and 169 bandwidth limits. Embedded sensors and clients face similar issues. 170 Mobile considerations require that HTTP be network efficient while 171 simultaneously being sensitive to the limited power, computation, and 172 connectivity capabilities of the client device. To support mobile 173 devices, HTTP needs to be able to "scale down" to allow clients to 174 control the level of data received, the format of that data, and even 175 the timing of that data. 177 1.1. Overview 179 This draft describes our proposal for "HTTP Speed+Mobility". The 180 approach targets broad HTTP applicability while emphasizing 181 performance improvements and accounting for the important needs of 182 mobile devices and applications. 184 The proposal's intended outcome is a protocol that can be quickly and 185 widely adopted in the industry, and start delivering real value to 186 end users without imposing undue burden on hardware and software 187 vendors, as well as administrators of legacy equipment. Implementers 188 should also find it easy to understand due to the familiarity of some 189 of its key concepts, which are aligned with innovations that were 190 adopted in recent IETF specifications like WebSockets. Most 191 important, the proposal seeks to establish a baseline for working 192 group discussion on the potential improvements that would define HTTP 193 2.0. 195 This HTTP Speed+Mobility proposal adheres to the following 196 principles: 198 o Maintain existing HTTP semantics. The request-response nature of 199 the HTTP protocol and semantics of its messages as they traverse 200 diverse networks must be preserved. Any deviation from this 201 principle would represent a major extension to HTTP and should be 202 treated as such (see section 2.1 in [I-D.iab-extension-recs]). 204 o Maintain the integrity of the layered architecture. 206 o Use existing standards when available to make it easy for the 207 protocol to work with the current web infrastructure including 208 switches, routers, proxies, load balancers, security systems, DNS 209 servers, and NATs. For example, the proposal reuses the 210 WebSockets handshake and framing mechanism to establish a 211 bidirectional link that is compatible with existing proxies and 212 connection models. 214 o Be as broadly applicable and flexible as the current protocol, and 215 keep the client in control of content. For example, the proposal 216 does not mandate the use of TLS or compression, leaving those 217 features up to the client to negotiate based on its specific 218 security, computation, and communication needs. 220 o Account for the needs of modern mobile clients, including power 221 efficiency and connectivity through costed networks. 223 These principles are described in more detail below. 225 1.1.1. Maintain existing HTTP semantics 227 HTTP at its core is a simple request-response protocol. The working 228 group has clearly stated that it is a goal to preserve the semantics 229 of HTTP. Thus, we believe that the request-response nature of the 230 HTTP protocol must be preserved. The core HTTP 2.0 protocol should 231 focus on optimizing these HTTP semantics, while improving the 232 transport via a new multiplexing layer. Additional capabilities that 233 introduce new communication models like unrequested responses should 234 be treated in a different specification and explored separately from 235 this proposal. 237 1.1.2. Layered Architecture 239 HTTP relies on an in-order, reliable transport to ensure delivery of 240 application data. TCP has almost exclusively provided the reliable, 241 ordered delivery of HTTP messages from one computer to another since 242 its inception. TCP accounts for adverse network conditions such as 243 congestion, or other unpredictable network behavior. Any HTTP 2.0 244 proposal should leverage the reliable transport and not attempt to 245 replicate functions generally accepted as addressed by other layers. 247 Conversely, any proposals for enhancing functionality typically 248 provided by other layers of the networking stack (e.g., congestion 249 control provided by the transport layer) should be brought to the 250 attention of, and discussed in, proper IETF forums (e.g., TCPM WG). 252 1.1.3. Use of Existing standards 254 HTTP 2.0 should prefer models that are compatible with the existing 255 Internet and, where possible, reuse existing protocol mechanisms. 256 One primary example is in protocol negotiation where the WG should 257 avoid a proliferation of methods, and instead use the HTTP 1.1 258 Upgrade header similar to how it is used in the WebSocket protocol. 259 This will help HTTP 2.0 to be readily deployed on the existing 260 Internet, and maintain compatibility with existing web sites and 261 client environments (such as some educational networks). 263 1.1.4. Client is in control of content 265 HTTP is used in a vast array of scenarios and a variety of network 266 architectures. There is no "one size fits all" deployment of HTTP. 267 For example, at times it may not be optimal to use compression in 268 certain environments. For constrained sensors from the "Internet of 269 things" scenario, resources may be at a premium. Having a high 270 performance but flexible HTTP 2.0 solution will enable 271 interoperability for a wider variety of scenarios. There also may be 272 aspects of security that are not appropriate for all implementations. 273 Encryption must be optional to allow HTTP 2.0 to meet certain 274 scenarios and regulations. HTTP 2.0 is a universal replacement for 275 HTTP 1.X, and there are some instances in which imposing TLS is not 276 required (or allowed). For example, a sizable portion of HTTP 277 requests and responses actually happen in "backend" scenarios, in 278 which the messages are transported over physically trusted 279 infrastructure between endpoints owned by the same organization. 280 Furthermore, a "random thought of the day" web service or a sensor 281 spewing out a temperature reading every few seconds may choose not to 282 use TLS. In such situations, it may not be worth the additional 283 expense of deploying TLS, nor might it be desirable to hinder caching 284 of the content by encrypting it end-to-end. 286 Because of the variety of clients on the Internet and the number of 287 connection scenarios, clients are in the best position to define what 288 content is downloaded. The browser or app has firsthand information 289 on what the app is currently doing and what data is already locally 290 available. For example, most of the browsers in use today have 291 powerful caches that should be leveraged to store web elements that 292 change infrequently. 294 In addition to browsers, apps increasingly originate HTTP requests. 295 The content retrieved by apps is usually different from that 296 downloaded by browsers; in fact, multiple apps may access the same 297 content for different purposes. Each app may access different 298 subsets of the server content, with different priorities, and in 299 different sequences according to their own rendering requirements and 300 user interaction models. The server cannot always know the needs or 301 intents of a particular application. 303 HTTP 2.0 proposals should not force the browser or app to download 304 content that has not been requested and that is already cached. 306 Furthermore, the client must have the option to decline unwanted or 307 unneeded content. Clients need the ability to inform the server 308 about cached elements that do not need to be downloaded. Ideally 309 this feedback from the client to the server would allow for 310 incremental approval of content to enable an efficient "push" 311 extension to deliver the right content, with the right security and 312 with the right formatting. 314 1.1.5. Network Cost and Power 316 Any new protocol for transporting HTTP data on the Internet must also 317 take into account the types of systems and devices that use HTTP and 318 how they are connected to the Internet. The growth of the Internet 319 of the next decade (and longer) will be fueled by mobile apps and 320 mobile devices, as well as by the cheap, limited-capability devices 321 envisioned by the "Internet of Things." For all these devices, speed 322 is only one design tenet: considerations about battery life, 323 bandwidth limitations, processor and memory constraints, and various 324 policy mandates will also challenge designers and users. For 325 instance, the user of a device connected over mobile broadband may 326 need to minimize the amount of data sent in order to conserve 327 bandwidth, minimize power usage and monetary cost of communication. 328 Furthermore, transmitting the same amount of data may have radically 329 different power implications depending on how the transfer is 330 structured: for example, when operating over a mobile broadband 331 interface it is more efficient to use a single larger transfer than 332 to space out the transmission in multiple smaller transfers. 333 Multiple transfers may cause multiple radio transitions between low 334 and high powered states, causing additional battery drain. 336 In short, the choice among speed, cost, and power is not a simple 337 one. At times, speed may be the most important consideration. Other 338 times, bandwidth cost or battery life may be the deciding factor. 339 HTTP 2.0 must allow developers to optimize for the specific 340 constraints of their problem space (which might change over time) 341 rather than imposing a monolithic solution to a generic problem. For 342 example, server push is a good optimization for many scenarios where 343 content updates to web pages revisited over time are infrequent, the 344 client has plenty of bandwidth as well as the needed processing power 345 to either handle the updates instantly, or cache them for later 346 processing. On the other hand, it is not likely to be appropriate in 347 situations where content is being transmitted over a costed link. 348 Neither will it be when the client is running several applications 349 that use network bandwidth concurrently, and bursty, server-initiated 350 content transmissions would interfere with their smooth operation. 351 Rather than forcing developers to choose between using all the 352 features of HTTP 2.0 or sticking with HTTP 1.1, it would be better to 353 provide mechanisms for developers to fine tune the capabilities of 354 HTTP 2.0 to a specific set of requirements. 356 In summary, the goals of higher speed, lower cost and lower power may 357 often be aligned. For instance, having less data sent on the wire 358 will allow pages to load faster, allow the radio to power down sooner 359 and consume less bandwidth. But given the variety of the scenarios 360 where HTTP 2.0 will be used, this will not always be the case. For 361 example, a device whose battery is about to run out, whose 362 communication monetary costs are prohibitive, or whose cache is near 363 capacity can provide a better user experience by disabling a 364 capability that consumes bandwidth with potentially unwanted content, 365 while continuing to use other optimizations available in HTTP 2.0. 366 Accordingly, the working group should consider power and cost as well 367 as speed. 369 1.2. Definitions 371 client: A program that establishes HTTP Speed+Mobility connections 372 for the purpose of sending requests. 374 connection: A TCP layer virtual circuit established between two 375 programs for the purpose of communication. 377 frame: A header-prefixed sequence of bytes sent over a HTTP Speed+ 378 Mobility WebSocket. 380 message: The basic unit of HTTP communication, consisting of a 381 structured sequence of octets matching the syntax defined in 382 [RFC2616] and transmitted via a connection. 384 request: An HTTP request message, as defined in [RFC2616]. 386 response: An HTTP response message, as defined in [RFC2616]. 388 server: An application program that accepts connections in order to 389 service requests by sending back responses. Any given program may 390 be capable of being both a client and a server; our use of these 391 terms refers only to the role being performed by the program for a 392 particular connection, rather than to the program's capabilities 393 in general. Likewise, any server may act as an origin server, 394 proxy, gateway, or tunnel, switching behavior based on the nature 395 of each request. 397 origin server: As defined in [RFC2616] section 1.3, a server on 398 which a given resource resides or is to be created. 400 origin: As defined in [RFC6454] section 3.2, a representation of a 401 security principal. Roughly speaking, two URIs are part of the 402 same origin if they have the same scheme, host, and port. 404 user agent: The client that initiates a request. These are often 405 browsers, editors, spiders (web-traversing robots), or other end 406 user tools. 408 proxy: An intermediary program that acts as both a server and a 409 client for the purpose of making requests on behalf of other 410 clients. Requests are serviced internally or by passing them on, 411 with possible translation, to other servers. A proxy MUST 412 implement both the client and server requirements of this 413 specification. A "transparent proxy" is a proxy that does not 414 modify the request or response beyond what is required for proxy 415 authentication and identification. A "non-transparent proxy" is a 416 proxy that modifies the request or response in order to provide 417 some added service to the user agent, such as group annotation 418 services, media type transformation, protocol reduction, or 419 anonymity filtering. Except where either transparent or non- 420 transparent behavior is explicitly stated, the HTTP proxy 421 requirements apply to both types of proxies. 423 endpoint: Either the client or server of a connection. 425 receiver: Endpoint receiving network data in a HTTP Speed+Mobility 426 session. This can be either the client or the server. 428 sender: Endpoint sending network data in a HTTP Speed+Mobility 429 session. This can be either the client or the server. 431 session: A single channel between a client and server over which 432 there will be multiplexed HTTP requests and responses. 434 session error: An error on the HTTP Speed+Mobility session. 436 stream: A bi-directional flow of bytes across a virtual channel 437 within a HTTP Speed+Mobility session. 439 stream error: An error on an individual stream. 441 1.3. Protocol Overview 443 HTTP Speed+Mobility is a proposal for an HTTP 2.0 transport protocol 444 that includes multiplexing HTTP content for improving transmission of 445 HTTP content and efficient use of TCP connections. 447 This protocol comprises four parts: 449 1. Negotiation: Setting up a session (Handshake) is the WebSocket 450 Upgrade with additional headers. 452 2. Session Layer: This defines maintenance and framing of a HTTP 453 Speed+Mobility session and is defined as a WebSocket extension 454 [RFC6455]. 456 3. Multiplexing Layer: This defines the framing and maintenance for 457 multiplexing HTTP requests over a single HTTP Speed+Mobility 458 session. This proposal borrows from the SPDY 459 [I-D.mbelshe-httpbis-spdy] stream semantics and is defined as a 460 WebSocket extension. 462 4. HTTP layering: This proposal borrows from the SPDY 463 [I-D.mbelshe-httpbis-spdy] proposal. 465 The WebSocket protocol [RFC6455] provides a standards-based model for 466 establishing a bi-directional session between a client and a server 467 across the web. The RFC describes the following: 469 o A mechanism to create a session between a client and a server 470 (Upgrade) and optionally secure the session using TLS 472 o A light-weight framing model to send data asynchronously and bi- 473 directionally within the session 475 o A set of control messages to keep the session alive (PING-PONG), 476 and to close the session (CLOSE) 478 o An extension model to optionally layer semantics such as 479 multiplexing and compression 481 In keeping with the principle to leverage existing standards where 482 possible, this HTTP Speed+Mobility proposal uses WebSockets as the 483 session layer between the client and the server. Using WebSockets as 484 a session layer has some advantages. First, we do not have to invent 485 a new set of control messages, since we can use the ones defined by 486 the WebSocket standard. Second, clients and servers have the 487 flexibility to decide whether they want to use TLS or not. 489 Using WebSockets also makes it easy to enable multiplexing within the 490 session. In fact, this proposal takes the concept of streams and the 491 stream related control messages, and models them as a WebSocket 492 extension. 494 Furthermore, this proposal specifies a simple receive buffer 495 management scheme based on a credit control mechanism. 497 Finally, this proposal regards server push as being outside of the 498 scope of HTTP 2.0 itself, because it is not in line with existing 499 HTTP semantics. Having said that, given the benefits of populating 500 the client cache proactively, we believe that the Working Group 501 should create a specification separate from HTTP 2.0 to define such a 502 solution. 504 1.3.1. Connection Management 506 By default, and because it reuses the WebSocket handshake, HTTP 507 Speed+Mobility uses port 80 for unsecured connections and port 443 508 for connections tunneled over Transport Layer Security (TLS) 509 [RFC2818]. 511 Clients SHOULD attempt to use a single HTTP Speed+Mobility connection 512 to a given origin server. The server MUST be able to handle multiple 513 connections from the same client and MUST be able to handle 514 concurrent establishments and disconnects. 516 1.4. Proxies 518 Based on the existing Internet, proxies are an important 519 consideration for any HTTP 2.0 proposal. There are many cases where 520 the presence of a proxy (both explicit and transparent) will impede 521 negotiation of any new protocol. In existing environments, the only 522 reliable method of traversing proxies with non-HTTP 1.x 523 communications is by tunneling over TLS / SSL. 525 However, given the importance of HTTP 2.0 and the desire to continue 526 to use proxies, we believe that proxies will eventually adopt HTTP 527 2.0 and will support communication without TLS, although such 528 adoption may take a long time. 530 WebSockets provides the best of both environments. WebSockets may be 531 negotiated over a secure tunnel to traverse an incompatible proxy or 532 may be used in the clear, when appropriate, with a proxy that 533 understands HTTP 2.0. 535 2. Negotiation 537 HTTP Speed+Mobility negotiates a session using the WebSockets 538 handshake based on HTTP Upgrade. To advertise support for the HTTP 539 2.0 extension, the client request MUST include the "x-httpsm" 540 extension token in the |Sec-WebSocket-Extensions| header in its 541 opening handshake: 543 GET /default.htm HTTP/1.1 544 Host: server.example.com 545 Upgrade: websocket 546 Connection: Upgrade, X-InitialCreditBalance 547 Origin: http://example.com 548 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 549 Sec-WebSocket-Version: 13 550 Sec-WebSocket-Extensions: x-httpsm 551 X-InitialCreditBalance: 131072 553 To accept the HTTP 2.0 extension requested by the client, the server 554 MUST include the "x-httpsm" extension token in the |Sec-WebSocket- 555 Extensions| header in its opening handshake. Otherwise, the client 556 MUST fail the WebSocket connection: 558 HTTP/1.1 101 Switching Protocols 559 Upgrade: websocket 560 Connection: Upgrade, X-InitialCreditBalance 561 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 562 Sec-WebSocket-Extensions: x-httpsm 563 X-InitialCreditBalance: 65536 565 The Sec-WebSocket-Extensions defines the version of the protocol. 566 For incompatible future revisions to the protocol, the extension name 567 will need to be revised. 569 This draft defines a new header to declare the initial credit balance 570 for endpoints that need to use flow control. This header is defined 571 in Section 5.3 below. 573 HTTP Speed+Mobility may be extended to allow for new negotiated 574 options by adding new headers to the upgrade exchange. 576 When the negotiation of HTTP Speed+Mobility is successful, the server 577 MUST respond to the GET request with a SYN_REPLY message with an 578 Stream ID of 1, containing the response to the original GET request. 579 Any required data frames for this response MUST be identified with 580 the stream ID of 1. For more information on SYN_REPLY see 581 Section 4.2.2 below. 583 For more details on WebSockets, refer to [RFC6455]. 585 3. Session layer and Framing 587 At the end of the WebSockets upgrade as described above, the bi- 588 directional WebSocket between the client and the server becomes the 589 new session layer. The session layer for HTTP Speed+Mobility uses 590 the WebSocket base framing protocol for both data frames and control 591 frames. 593 3.1. Opening and Closing Sessions 595 One of the motivations for a multiplexing solution is to have a more 596 efficient use of the TCP transport. Implementations should minimize 597 the number of connections to reduce the impact of TCP slow start and 598 to avoid latency from creating new connections. Ideally there will 599 be a single session between a client and a server. An implementation 600 SHOULD use this session to multiplex the maximum amount of data 601 between the two endpoints. Implementations MAY create multiple 602 simultaneous sessions between two endpoints. 604 For best performance, it is expected that a client will not close 605 open TCP connections until it is certain that it no longer has use 606 for it (e.g., the user closes the HTTP app or navigates away from all 607 web pages referencing a connection), or until the server closes the 608 connection. Servers SHOULD leave connections open for as long as 609 possible, but MAY terminate idle connections if necessary. 611 3.2. Origin of Multiplexed Content 613 A single session MAY contain HTTP content from multiple origins. A 614 client implementation SHOULD only multiplex requests destined to 615 multiple origins into a single connection under the following 616 conditions: 618 o Anonymous / Clear: For sessions that do not require authentication 619 or SSL/TLS, implementations MAY multiplex content to multiple 620 origins in the same session. This is the primary use case for 621 sending requests to a Proxy. 623 o Basic / Digest Authentication: For sessions to an origin server 624 that requires per-request authentication, implementations MAY 625 multiplex content to multiple origins. 627 o Multi-Part Authentication (e.g., Kerberos): To be done. 629 o For a secure connection, if the client provides a Server Name 630 Indication (SNI) extension during the TLS handshake then all 631 subsequent SYN_STREAM messages (see Section 4.2.1) on that 632 connection MUST specify a Host specification that exactly matches 633 the server name provided in the Server Name Indication (SNI) 634 (Section 3.1 of [RFC4366]). If the server receives a SYN_STREAM 635 with a non-matching Host specification then it MUST respond with a 636 400 Bad Request. If the client receives a SYN_STREAM with a non- 637 matching Host specification then it MUST issue a stream error. 639 3.3. WebSocket Framing Protocol 641 This specification defines the x-httpsm WebSocket extension to enable 642 multiplexing of HTTP content within a single WebSocket session. Once 643 the upgrade is accepted, the client and server can exchange framed 644 messages using the WebSockets framing protocol. The standard 645 WebSocket frame from [RFC6455] is included for reference. 647 0 1 2 3 648 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 649 +-+-+-+-+-------+-+-------------+-------------------------------+ 650 |F|R|R|R| opcode|M| Payload len | Extended payload length | 651 |I|S|S|S| (4) |A| (7) | (16/64) | 652 |N|V|V|V| |S| | (if payload len==126/127) | 653 | |1|2|3| |K| | | 654 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + 655 | Extended payload length continued, if payload len == 127 | 656 + - - - - - - - - - - - - - - - +-------------------------------+ 657 | |Masking-key, if MASK set to 1 | 658 +-------------------------------+-------------------------------+ 659 | Masking-key (continued) | Payload Data | 660 +-------------------------------- - - - - - - - - - - - - - - - + 661 : Payload Data continued ... : 662 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 663 | Payload Data continued ... | 664 +---------------------------------------------------------------+ 666 The payload data for this extension is multiplexed streams as defined 667 in Section 4 below. 669 The x-httpsm extension defines 4 extension opcodes to establish and 670 maintain streams: 672 (opcode TBD) - SYN_STREAM: See Section 4.2.1. 674 (opcode TBD) - SYN_REPLY: See Section 4.2.2. 676 (opcode TBD) - RST_STREAM: See Section 4.2.3. 678 (opcode TBD) - CREDIT_UPDATE: See Section 4.2.4. 680 3.4. Closing HTTP Speed+Mobility Sessions 682 Closing a session uses the standard WebSocket close handshake as 683 defined in [RFC6455]. 685 For best performance, it is expected that clients will not close open 686 TCP connections until the user closes the HTTP app or navigates away 687 from all web pages referencing a connection, or until the server 688 closes the connection. Servers are encouraged to leave connections 689 open for as long as possible, but can terminate idle connections if 690 necessary. 692 4. Streams Layer 694 Once the session is established, HTTP Speed+Mobility allows creating 695 streams to send and receive HTTP data. The stream operations and 696 semantics are borrowed from SPDY. As noted earlier, WebSockets is 697 the protocol used for framing data that is sent and received within 698 the session (and consequently each stream). Stream operations (such 699 as SYN_STREAM) are implemented as a WebSocket extension. 701 4.1. Stream Management 703 4.1.1. Stream Creation 705 A stream is created by sending a SYN_STREAM (Section 4.2.1). The 706 first stream is created by the GET request that initiates the upgrade 707 to HTTP Speed+Mobility and will have a stream ID of 1. Each 708 subsequent SYN_STREAM sent by the client will increment the stream ID 709 by 1. Stream IDs do not wrap; when a client or server cannot create 710 a new stream id without exceeding a 32 bit value, it MUST NOT create 711 a new stream. 713 If a server receives a SYN_STREAM with a stream id which is less than 714 any previously received SYN_STREAM, it MUST issue a session error 715 (Section 4.1.5.1) with the status PROTOCOL_ERROR. 717 It is a protocol error to send two SYN_STREAMs with the same 718 stream-ID. If a recipient receives a second SYN_STREAM for the same 719 stream, it MUST issue a stream error (Section 4.1.5.2) with the 720 status code PROTOCOL_ERROR. 722 Upon receipt of a SYN_STREAM, the recipient can reject the stream by 723 sending a stream error (Section 4.1.5.2) with the error code 724 REFUSED_STREAM. Note, however, that the creating endpoint may have 725 already sent additional frames for that stream which cannot be 726 immediately stopped. 728 Once the stream is created, the creator may immediately send data 729 frames for that stream, without needing to wait for the recipient to 730 acknowledge. 732 Both endpoints can send data on the stream. 734 4.1.2. Stream Data Exchange 736 Once a stream is created, it can be used to send arbitrary amounts of 737 data. Generally this means that a series of data frames will be sent 738 on the stream until a frame containing the FLAG_FIN flag is set. The 739 FLAG_FIN can be set on a SYN_STREAM (Section 4.2.1), SYN_REPLY 740 (Section 4.2.2), or a data (Section 4.3) frame. Once the FLAG_FIN 741 has been sent, the stream is considered to be half-closed. 743 4.1.3. Stream Half-Close 745 When one side of the stream sends a frame with the FLAG_FIN flag set, 746 the stream is half-closed from that endpoint. The sender of the 747 FLAG_FIN MUST NOT send further frames on that stream. When both 748 sides have half-closed, the stream is closed. 750 If an endpoint receives a data frame after the stream is half-closed 751 from the sender (e.g. the endpoint has already received a prior frame 752 for the stream with the FIN flag set), it MUST send a RST_STREAM to 753 the sender with the status STREAM_ALREADY_CLOSED. 755 4.1.4. Stream Close 757 There are 3 ways that streams can be terminated: 759 Normal termination: Normal stream termination occurs when both 760 sender and recipient have half-closed the stream by sending a 761 FLAG_FIN. 763 Abrupt termination: Either the client or server can send a 764 RST_STREAM at any time. A RST_STREAM contains an error code to 765 indicate the reason for failure. When a RST_STREAM is sent from 766 the stream originator, it indicates a failure to complete the 767 stream and that no further data will be sent on the stream. When 768 a RST_STREAM is sent from the stream recipient, the sender, upon 769 receipt, should stop sending any data on the stream. The stream 770 recipient should be aware that there is a race between data 771 already in transit from the sender and the time the RST_STREAM is 772 received. See Stream Error Handling (Section 4.1.5.2). 774 TCP connection teardown: If the TCP connection is torn down while 775 un-closed streams exist, then the endpoint must assume that the 776 stream was abnormally interrupted and may be incomplete. 778 If an endpoint receives a data frame after the stream is closed, it 779 must send a RST_STREAM to the sender with the status PROTOCOL_ERROR. 781 4.1.5. Error Handling 783 The framing layer has only two types of errors, and they are always 784 handled consistently. Any reference in this specification to "issue 785 a session error" refers to Section 4.1.5.1. Any reference to "issue 786 a stream error" refers to Section 4.1.5.2. 788 4.1.5.1. Session Error Handling 790 A session error is any error which prevents further processing of the 791 session layer or which corrupts the session compression state. When 792 a session error occurs, the endpoint encountering the error MUST send 793 a WebSockets CLOSE [RFC6455]. 795 4.1.5.2. Stream Error Handling 797 A stream error is an error related to a specific stream-id which does 798 not affect processing of other streams at the session layer. Upon a 799 stream error, the endpoint MUST send a RST_STREAM (Section 4.2.3) 800 frame which contains the stream id of the stream where the error 801 occurred and the error status which caused the error. After sending 802 the RST_STREAM, the stream is closed to the sending endpoint. After 803 sending the RST_STREAM, if the sender receives any frames other than 804 a RST_STREAM for that stream id, it will result in sending additional 805 RST_STREAM frames. An endpoint MUST NOT send a RST_STREAM in 806 response to an RST_STREAM, as doing so would lead to RST_STREAM 807 loops. Sending a RST_STREAM does not cause the HTTP Speed+Mobility 808 session to be closed. 810 If an endpoint has multiple RST_STREAM frames to send in succession 811 for the same stream-id and the same error code, it MAY coalesce them 812 into a single RST_STREAM frame. 814 4.2. Stream Control Frames 816 In Speed+Mobility four new opcodes are introduced: 818 o SYN_STREAM 820 o SYN_REPLY 822 o RST_STREAM 824 o CREDIT_UPDATE 826 In addition, all frames in HTTP Speed+Mobility include a 32-bit 827 stream identifier in the Extension data. 829 4.2.1. SYN_STREAM 831 The SYN_STREAM control frame is used to initiate a new stream and 832 send the headers for a request. SYN_STREAM is specified as the 833 extension opcode in the WebSocket frame. The SYN_STREAM Extension 834 data is carried in the WebSocket payload: 836 0 1 2 3 837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 838 +---------------------------------------------------------------+ 839 | Stream-ID | 840 +---------------------------------------------------------------+ 841 | Flags | Pri | Unused | 842 +---------------------------------------------------------------+ 843 | Length of name | 844 +---------------------------------------------------------------+ 845 | Name | 846 +---------------------------------------------------------------+ 847 | Length of value | 848 +---------------------------------------------------------------+ 849 | Value | 850 +---------------------------------------------------------------+ 851 | (repeats) | 852 +---------------------------------------------------------------+ 854 Flags: Flags related to this frame. Valid flags are: 856 0x01 = FLAG_FIN: marks this frame as the last frame to be 857 transmitted on this stream and puts the sender in the half-closed 858 (Section 4.1.3) state. 860 0x02 = FLAG_NO_HEADER_COMPRESSION: indicates the Name/Value header 861 block is not compressed. 863 Priority: A 3-bit priority (Section 5.1) field. 865 Unused: 21 bits of unused space, reserved for future use. 867 Name/Value Header Block: A set of name/value pairs carried as part of 868 the SYN_STREAM. See Section 4.4. 870 4.2.2. SYN_REPLY 872 The SYN_REPLY control frame indicates the acceptance of a stream 873 creation by the recipient of a SYN_STREAM control frame. SYN_REPLY 874 is specified as the extension opcode in the WebSocket frame. The 875 SYN_REPLY Extension data is carried in the WebSocket payload: 877 0 1 2 3 878 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 879 +---------------------------------------------------------------+ 880 | Stream-ID | 881 |---------------+-----------------------------------------------| 882 | Flags | Unused | 883 +---------------+-----------------------------------------------+ 884 | Length of name | 885 +---------------------------------------------------------------+ 886 | Name | 887 +---------------------------------------------------------------+ 888 | Length of value | 889 +---------------------------------------------------------------+ 890 | Value | 891 +---------------------------------------------------------------+ 892 | (repeats) | 893 +---------------------------------------------------------------+ 895 Flags: Flags related to this frame. Valid flags are: 897 0x01 = FLAG_FIN: marks this frame as the last frame to be 898 transmitted on this stream and puts the sender in the half-closed 899 (Section 4.1.3) state. 901 0x02= FLAG_NO_HEADER_COMPRESSION: indicates the Name/Value header 902 block is not compressed. 904 Name/Value Header Block: A set of name/value pairs carried as part of 905 the SYN_STREAM. See Section 4.4. 907 4.2.3. RST_STREAM 909 The RST_STREAM control frame allows for abnormal termination of a 910 stream. When sent by the creator of a stream, it indicates the 911 creator wishes to cancel the stream. When sent by the recipient of a 912 stream, it indicates an error or that the recipient did not want to 913 accept the stream, so the stream should be closed. RST_STREAM is 914 specified as the extension opcode in the WebSocket frame. The 915 RST_STREAM Extension data is carried in the WebSocket payload: 917 0 1 2 3 918 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 919 +---------------------------------------------------------------+ 920 | Stream-ID | 921 +-------------------------------+-------------------------------+ 922 | Status Code | 923 +-------------------------------+ 924 Status code (16 bits): An indicator for why the stream is being 925 terminated. The following status codes are defined: 927 1 - PROTOCOL_ERROR: This is a generic error, and should only be used 928 if a more specific error is not available. 930 2 - INVALID_STREAM: This is returned when a frame is received for a 931 stream which is not active. 933 3 - REFUSED_STREAM: Indicates that the stream was refused before any 934 processing has been done on the stream. 936 5 - CANCEL: Used by the creator of a stream to indicate that the 937 stream is no longer needed. 939 6 - INTERNAL_ERROR: This is a generic error which can be used when 940 the implementation has internally failed, not due to anything in 941 the protocol. 943 7 - FLOW_CONTROL_ERROR: The endpoint detected that its peer violated 944 the flow control protocol. 946 8 - STREAM_IN_USE: The endpoint received a SYN_REPLY for a stream 947 already open. 949 9 - STREAM_ALREADY_CLOSED: The endpoint received a data or SYN_REPLY 950 frame for a stream which is half closed. 952 Note: 0 is not a valid status code for a RST_STREAM. 954 After receiving a RST_STREAM on a stream, the recipient must not send 955 additional frames for that stream, and the stream moves into the 956 closed state. 958 4.2.4. CREDIT_UPDATE 960 0 1 2 3 961 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 962 +---------------------------------------------------------------+ 963 | Stream-ID | 964 +---------------------------------------------------------------+ 965 | Credit-Addition | 966 +---------------------------------------------------------------+ 968 Credit-Addition: The value, in bytes, that the recipient must add to 969 the stream's credit balance. The value ranges from 0 to 4294967295 970 (0xffffffff) inclusive. 4294967295 (0xffffffff) is a special value 971 that designates "infinite" (see Section 5.5). 973 4.3. Data Frames 975 0 1 2 3 976 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 977 +---------------------------------------------------------------+ 978 | Stream-ID | 979 +---------------+-----------------------------------------------+ 980 | Flags | 981 +---------------+ 983 Stream data frames are modeled as WebSocket binary data frames with 984 extension data: 986 Flags: Flags related to this frame. Valid flags are: 988 0x01 = FLAG_FIN: signifies that this frame represents the last frame 989 to be transmitted on this stream. See Stream Close 990 (Section 4.1.4) below. 992 Data frame processing requirements: 994 If an endpoint receives a data frame for a stream-id which is not 995 open, it MUST send issue a stream error (Section 4.1.5.2) with the 996 error code INVALID_STREAM for the stream-id. 998 If the endpoint which created the stream receives a data frame 999 before receiving a SYN_REPLY on that stream, it is a protocol 1000 error, and the recipient MUST issue a stream error 1001 (Section 4.1.5.2) with the status code PROTOCOL_ERROR for the 1002 stream-id. 1004 4.4. Name/Value Header Block 1006 The Name/Value Header Block is found in the SYN_STREAM and SYN_REPLY 1007 control frames, and shares a common format: 1009 +------------------------------------+ 1010 | Number of Name/Value pairs (int32) | 1011 +------------------------------------+ 1012 | Length of name (int32) | 1013 +------------------------------------+ 1014 | Name (string) | 1015 +------------------------------------+ 1016 | Length of value (int32) | 1017 +------------------------------------+ 1018 | Value (string) | 1019 +------------------------------------+ 1020 | (repeats) | 1022 Number of Name/Value pairs: The number of repeating name/value pairs 1023 following this field. 1025 List of Name/Value pairs: 1027 Length of Name: a 32-bit value containing the number of octets in 1028 the name field. 1030 Name: 0 or more octets, 8-bit sequences of data, excluding 0. 1032 Length of Value: a 32-bit value containing the number of octets in 1033 the value field. 1035 Value: 0 or more octets, 8-bit sequences of data, excluding 0. 1037 Each header name must have at least one value. Header names are 1038 encoded using the US-ASCII character set and must be all lower case. 1039 The length of each name must be greater than zero. A recipient of a 1040 zero-length name MUST issue a stream error (Section 4.1.5.2) with the 1041 status code PROTOCOL_ERROR for the stream-id. 1043 Duplicate header names are not allowed. To send two identically 1044 named headers, send a header with two values, where the values are 1045 separated by a single NUL (0) byte. A header value can either be 1046 empty (e.g. the length is zero) or it can contain multiple, NUL- 1047 separated values, each with length greater than zero. The value 1048 never starts nor ends with a NUL character. Recipients of illegal 1049 value fields MUST issue a stream error (Section 4.1.5.2) with the 1050 status code PROTOCOL_ERROR for the stream-id. 1052 4.5. Compression 1054 The Name/Value Header Block is a section of the SYN_STREAM and 1055 SYN_REPLY frames used to carry header meta-data. This block MAY be 1056 compressed using zlib compression. Within this specification, any 1057 reference to 'zlib' is referring to the ZLIB Compressed Data Format 1058 Specification Version 3.3 as part of [RFC1950]. 1060 For each HEADERS compression instance, the initial state is 1061 initialized using the dictionary specified in 1062 [I-D.mbelshe-httpbis-spdy] section 2.6.10.1. 1064 Implementations MUST support header compression as specified in 1065 [I-D.mbelshe-httpbis-spdy] except for the following. 1067 Throughout this document, header compression is enabled by default. 1068 However, either the client or the server MAY opt out of using 1069 compression when transmitting headers. This opt out model is 1070 described with added flags in the SYN_STREAM, HEADERS and SYN_REPLY 1071 frames. 1073 5. Flow Control 1075 5.1. Stream Priority 1077 Each stream has a 3-bit priority field where 7 represents the highest 1078 priority and 0 represents the lowest priority. The stream priority 1079 is specified in the SYN_STREAM and cannot be re-specified for the 1080 lifetime of the stream. 1082 When selecting data to send, the sender SHOULD select the data from 1083 the highest priority stream that has data ready for transmission. If 1084 multiple streams of the same priority have data ready for 1085 transmission then the sender SHOULD be fair in sending data between 1086 those streams. See Section 5.7. 1088 5.2. Credit Control 1090 Credit control is used by memory-sensitive endpoints to advertise 1091 their limited buffering capability. This is to prevent the sender 1092 from sending too much data, in a given time interval, thus causing 1093 the recipient's buffers to overflow. 1095 An endpoint MAY demand that its peer honor credit control. An 1096 endpoint MUST honor the credit control if the peer demands it. 1097 Section 5.3 explains how an endpoint demands credit control. 1099 Credit control is directional and is demanded by an endpoint to 1100 control how much its peer can send. 1102 An endpoint that is honoring its peer's credit control will maintain 1103 a credit balance, for each stream, that controls how much data the 1104 endpoint can send to its peer. The credit balance is always in units 1105 of bytes. The demanding endpoint will send CREDIT_UPDATE messages, 1106 for a given stream, to update how much data the honoring peer is 1107 allowed to send. The credit balance applies to the data payload of 1108 data frames. Credit control is applied on an HTTP S+M per-hop basis. 1110 5.3. Credit Control Declaration 1112 During the HTTP S+M handshake, an endpoint MAY demand that the peer 1113 honor credit control when sending data, for all streams, on that 1114 connection. If the endpoint does not demand credit control, then it 1115 MUST NOT send CREDIT_UPDATE messages. 1117 Credit control is demanded by specifying an HTTP header in the GET 1118 that upgrades the HTTP/1.1 connection to HTTP S+M. The header name is 1119 "X-InitialCreditBalance". The header value indicates the initial 1120 credit balance that the peer has for sending data on streams. The 1121 header value is a base-10 number ranging from 0 to 4294967294 1122 (0xfffffffe), inclusive. If the header is not present then that 1123 indicates the endpoint does not advertise credits and will never send 1124 CREDIT_UPDATE messages on that connection. 1126 In the following example, the client does not advertise flow control 1127 because it wants uninhibited responses throughput. Thus the server 1128 will send data frames to the client without credit tracking. 1129 However, the server indicates an initial credit balance of 64KB, 1130 which means the client will keep track of the CREDIT_UPDATE messages 1131 from the server to know when it can send data frames for a given 1132 stream. 1134 Upgrade Request: 1136 GET / default.htm HTTP/1.1 1137 Host: server.example.com 1138 Upgrade: websocket 1139 Connection: Upgrade 1140 Origin: http://example.com 1141 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 1142 Sec-WebSocket-Version: 13 1143 Sec-WebSocket-Extensions: x-httpsm 1145 Upgrade Response: 1147 HTTP/1.1 101 Switching Protocols 1148 Upgrade: websocket 1149 Connection: Upgrade, X-InitialCreditBalance 1150 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 1151 Sec-WebSocket-Extensions: x-httpsm 1152 X-InitialCreditBalance: 65536 1154 5.4. Credit Balance Updates 1156 If an endpoint is honoring credit control then the endpoint MUST 1157 maintain a credit balance for each of the streams on that connection. 1158 The client MUST NOT send more data than there is credit available. 1159 Upon sending a data frame, the endpoint MUST decrement the credit 1160 balance by the number of bytes in the payload of the data frame. 1161 Upon receipt of a CREDIT_UPDATE message, the endpoint MUST increment 1162 the credit balance by the amount indicated in the CREDIT_UPDATE 1163 message. If the resultant sum exceeds 4294967294 (0xfffffffe) then 1164 that is a stream error. The demanding endpoint knows the initial 1165 credit balance and the amount of data received thus far so it MUST 1166 NOT emit a CREDIT_UPDATE message that would cause the credit balance 1167 to exceed 4294967294 (0xfffffffe). 1169 5.5. Turning Credit Control Off for a Stream 1171 If an endpoint demanded credit control then all streams start with 1172 the specified initial credit balance. Any time, before having sent a 1173 frame with FLAG_FIN set on the stream, the demanding endpoint MAY 1174 emit an "infinite" CREDIT_UPDATE message to terminate any further 1175 credit control on that stream. Upon sending an "infinite" 1176 CREDIT_UPDATE, the sender MUST NOT send any more CREDIT_UPDATE 1177 messages for that stream. Upon receipt of an "infinite" 1178 CREDIT_UPDATE message, the sender has an unlimited number of credits. 1180 5.6. Increasing and Decreasing Stream Credit 1182 An endpoint MAY increase the credit available to the peer by 1183 specifying a value in the CREDIT_UPDATE message that is larger than 1184 how much data was sent by the peer or consumed. For example, having 1185 demanded an initial credit balance of 64KB, the endpoint may send a 1186 CREDIT_UPDATE of 512KB for a newly created stream shortly after 1187 creation, thus increasing the available credit for that stream to 1188 576KB. 1190 An endpoint MAY replenish less credit by specifying a value in the 1191 CREDIT_UPDATE message that is smaller than how much data was actually 1192 consumed. For example, after demanding an initial credit balance of 1193 64KB and upon receiving 40KB of data, the endpoint may not send back 1194 a CREDIT_UPDATE message thus forcing the available credit down to 1195 24KB. Note that it is not possible for an endpoint to revoke credit 1196 that it already advertised to the peer. 1198 5.7. Implementation Guidance and Considerations 1200 This document does not mandate a specific algorithm for selecting 1201 data to send from amongst multiple streams. The exact logic used 1202 will be implementation-specific. Within a priority level, the 1203 implemented algorithm should try to be fair to avoid one or more 1204 streams from monopolizing the send opportunities and hence starving 1205 the other streams. One such solution would be to implement a Deficit 1206 Round Robin scheme within a priority class and have a higher priority 1207 always preempt a lower priority. 1209 This document does not mandate a specific algorithm for deciding when 1210 to send CREDIT_UPDATE messages. For example, a simple implementation 1211 may always emit a CREDIT_UPDATE immediately upon consuming the 1212 received data. Another implementation may coalesce multiple 1213 CREDIT_UPDATE messages into one. Yet another implementation may 1214 delay emitting a CREDIT_UPDATE message until a specific time or the 1215 next set of received data, whichever comes first, to reduce packet 1216 chatter. 1218 This document does not mandate a specific algorithm for adjusting the 1219 credit balance. For example, implementations may monitor their 1220 memory state to determine when they can afford to increase or reduce 1221 the credit balance. Other implementations may also interface with 1222 the lower stack layers (e.g., TCP) to compute bandwidth-delay- 1223 products to tune the credit balance. Some implementations (e.g., 1224 devices) may be very constrained and may not have any logic to tune 1225 the credit balance. 1227 6. General Notes 1229 6.1. HTTP Layering 1231 This proposal adopts the HTTP integration model used by SPDY. The 1232 request-response semantics would be the same as well as stateless 1233 authentication. 1235 This proposal does not support some HTTP concepts as documented in 1236 [RFC2616] including Chunked Encoding and HTTP trailers. 1238 While not addressed in this proposal, stateful authentication is 1239 something that will be addressed at a later date 1241 6.2. Relationship to SPDY 1243 This proposal borrows on many of the concepts of the SPDY proposal. 1244 There are some key areas where we differ from SPDY as outlined below. 1246 Much of where HTTP Speed+Mobility differs from SPDY are a result of 1247 its relationship with WebSockets where we use the existing standard 1248 for the following: 1250 Negotiation: Uses WebSockets Upgrade. This also negotiates streams 1251 settings and version allowing the simplification of the streams 1252 frames 1254 Session Framing: Defined as a WebSockets Extension. Allows reuse of 1255 the length and opcode data to simplify the streams frames. 1257 Lastly, this document simplifies the number of messages in the 1258 streams layer. 1260 6.3. Server Push 1262 Server push is a new concept introduced in [I-D.mbelshe-httpbis-spdy] 1263 wherein a server pushes content to a client even if the client may 1264 not have requested it. This is an area that requires significant 1265 working group discussion. Given the principle around maintaining 1266 existing HTTP semantics, we are not documenting it here and would 1267 like to see the working group document this separately from HTTP 2.0. 1269 6.4. Open Issues 1271 There are a number of open issues that are still under investigation. 1272 This is by no means a complete list of discussions around HTTP 2.0 1273 but simply the current list of issues that the authors of this 1274 document wanted to explore further. 1276 6.4.1. Flow Control 1278 Describe how intermediaries may add/ adjust credit control 1279 parameters. 1281 Deeper investigation into frame buffering requirements. 1283 What to do if a control frame is too big. What to do in the case of 1284 a buffer overrun. 1286 Do we want to add the ability to change priority on a stream? 1288 6.4.2. Streams Issues 1290 Do we need to negotiate maximum streams in the Upgrade header? 1292 7. Acknowledgements 1294 Thanks to the following individuals who provided helpful feedback and 1295 contributed to discussions on this document: Dave Thaler, Ivan 1296 Pashov, Jitu Padhye, Jean Paoli, Michael Champion, NK Srinivas, 1297 Sharad Agarwal and Rob Mauceri. 1299 This document incorporates materials from [I-D.mbelshe-httpbis-spdy]. 1301 8. References 1303 8.1. Normative References 1305 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1306 Specification version 3.3", RFC 1950, May 1996. 1308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1309 Requirement Levels", BCP 14, RFC 2119, March 1997. 1311 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1312 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1313 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1315 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1317 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1318 and T. Wright, "Transport Layer Security (TLS) 1319 Extensions", RFC 4366, April 2006. 1321 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1322 December 2011. 1324 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1325 RFC 6455, December 2011. 1327 [I-D.mbelshe-httpbis-spdy] 1328 Belshe, M. and R. Peon, "SPDY Protocol", 1329 draft-mbelshe-httpbis-spdy-00 (work in progress), 1330 February 2012. 1332 8.2. Informative References 1334 [I-D.iab-extension-recs] 1335 Carpenter, B., Aboba, B., and S. Cheshire, "Design 1336 Considerations for Protocol Extensions", 1337 draft-iab-extension-recs-14 (work in progress), June 2012. 1339 Authors' Addresses 1341 Rob Trace 1342 Microsoft 1344 Email: Rob.Trace@microsoft.com 1346 Adalberto Foresti 1347 Microsoft 1349 Email: aforesti@microsoft.com 1351 Sandeep Singhal 1352 Microsoft 1354 Email: Sandeep.Singhal@microsoft.com 1356 Osama Mazahir 1357 Microsoft 1359 Email: OsamaM@microsoft.com 1361 Henrik Frystyk Nielsen 1362 Microsoft 1364 Email: HenrikN@microsoft.com 1366 Brian Raymor 1367 Microsoft 1369 Email: Brian.Raymor@microsoft.com 1371 Ravi Rao 1372 Microsoft 1374 Email: RaviRao@microsoft.com 1375 Gabriel Montenegro 1376 Microsoft 1378 Email: Gabriel.Montenegro@microsoft.com