idnits 2.17.1 draft-zhu-http-fullduplex-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2010) is 5086 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Zhu 3 INTERNET-DRAFT Google, Inc. 4 Intended Status: Informational M. Jennings 5 Expires: November 25, 2010 May 24, 2010 7 Implications of Full-Duplex HTTP 8 draft-zhu-http-fullduplex-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright and License Notice 33 Copyright (c) 2010 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Abstract 48 Full-duplex HTTP follows the basic HTTP request-response semantics 49 but also allows the server to send the response to the client at the 50 same time that the client is transmitting the request to the server. 51 Requirements for Full-duplex HTTP are under-specified in the existing 52 HTTP specification, and this memo intends to clarify the requirements 53 for implementing Full-duplex HTTP under the standard HTTP protocol. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Streaming in HTTP . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1 Request and Response Streaming . . . . . . . . . . . . . . 3 61 2.2 Full-Duplex Streaming . . . . . . . . . . . . . . . . . . . 4 62 3 Protocol Considerations . . . . . . . . . . . . . . . . . . . . 4 63 3.1 Initialization . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2 Termination . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3 Persistent Connections . . . . . . . . . . . . . . . . . . 5 66 3.4 Time-Out . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.5 Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.6 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4 Application Considerations . . . . . . . . . . . . . . . . . . . 6 70 4.1 Compatibility . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2 Fall Back . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.3 Buffering . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.4 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 75 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 76 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 77 8 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 78 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1 Introduction 82 HTTP [RFC2616] is a stateless, RPC style protocol which requires 83 communication between client and server follows a strict request- 84 response pattern. 86 HTTP may also be used to stream data from either client or server. 87 When bi-directional streaming is required, two connections are often 88 used to stream client and server data separately. Using two separate 89 connections not only introduce overhead, but also make HTTP 90 insufficient to be used as a standalone protocol, i.e. application- 91 level protocols are required to handle the two connections. 93 However, if the server is allowed to send the response to the client 94 at the same time that a request is being transmitted from the client 95 to the server, then effectively full-duplex streaming becomes 96 possible under the standard HTTP protocol [RFC2616]. 98 Full-duplex streaming requires end-to-end support from both the 99 client and server. More specifically, the client has to be explicitly 100 designed to support such capability. 102 Given the unique properties of full-duplex HTTP, special requirements 103 exist for both the client and server. And those requirements need be 104 identified so that implementations will be able to follow standard 105 behaviors in adopting full-duplex HTTP. 107 1.1 Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2 Streaming in HTTP 115 2.1 Request and Response Streaming 117 Request streaming requires the server to deliver to the application 118 in real-time any streaming data that has been received by the server. 120 Response streaming requires the server to send to the client in real- 121 time any streaming data that has been produced by the application. 123 Chunked transfer-encoding [RFC2616] is expected for both request and 124 response streaming. However, client or server should not design the 125 underlying streaming or messaging API based on the chunked transfer- 126 encoding (which is generated hop-by-hop). 128 Most browsers don't support chunked transfer-encoding for requests. 130 2.2 Full-Duplex Streaming 132 When full-duplex streaming is enabled, request and response are 133 transmitted between client and server simultaneously over the same 134 HTTP connection. 136 Full-duplex streaming may be applied to any resource that is designed 137 to concurrently stream request and response, for example a voice 138 translator. 140 Full-duplex streaming should still follow the standard request- 141 response semantics and maintain the basic temporal dependency between 142 request and response: 144 1 A server SHOULD NOT generate any response until it has received a 145 new request. That is, unsolicited server-initiated response is not 146 allowed. 148 2 A server SHOULD NOT complete the response when the client has not 149 completed the request. That is, a server can only complete the 150 response after it has received the complete request from the 151 client. 153 3 Protocol Considerations 155 3.1 Initialization 157 Full-duplex streaming may be started as soon as the server receives 158 the first byte of the request body. This behavior is significantly 159 different from the technique commonly-known as Hanging GET, in which 160 a separate GET request is issued to initiate streaming to the client. 162 3.2 Termination 164 A client terminates request streaming by completing the request, i.e. 165 sending out the last-chunk [RFC2616]. And the server may choose to 166 continue streaming the response after it receives the complete 167 request from the client as decided by the application. Eventually the 168 server terminates response streaming by sending out the last-chunk of 169 response. 171 Before a server receives the complete request from the client, the 172 only way for the server to terminate response streaming is to close 173 the connection. It is considered an illegal state for an HTTP 174 connection to have a pending request when the response has already 175 been completed. A client should close the connection immediately if 176 it receives a complete response when it is still streaming the 177 request. 179 3.3 Persistent Connections 181 It's important that HTTP keep-alive and pipelining still work with 182 full-duplex HTTP. To achieve that, the client and server should 183 respect the original semantics of HTTP persistent connections 184 [RFC2616]. 186 Request streaming will make the connection unavailable for pipelined 187 requests. Also, continuing response streaming after the request has 188 been completed will prevent any pipelined requests from being 189 processed. 191 3.4 Time-Out 193 HTTP server or client may time-out connections while waiting for 194 request or response. Full-duplex HTTP should not override this 195 behavior. A connection may be closed due to time-out when either 196 request or response streaming becomes inactive. 198 Full-duplex HTTP introduces no special requirements on time-out of 199 the underlying TPC connection. When time-out does happen both request 200 and response streaming will be terminated. 202 3.5 Proxies 204 HTTP proxies may not support concurrent responses, and one of the 205 purposes of this document is to increase awareness of full-duplex 206 HTTP communication in proxies. 208 Proxies may also buffer streamed requests or responses, or have 209 problems to handle chunked transfer-encoding, especially for 210 requests. 212 3.6 Errors 214 According to RFC2616 [RFC2616], a client should close the connection 215 if it receives an error response when it is still transmitting the 216 request. Full-duplex HTTP must respect this requirement. 218 When a server is incapable of streaming response or decides to 219 timeout, it should close the connection. This is also true for the 220 client when it is streaming request. 222 A client or server should stop streaming any new data after it 223 notices that the underlying TCP connection has been closed by the 224 other party. In-flight data will be discarded under such a half-close 225 behavior. 227 4 Application Considerations 229 4.1 Compatibility 231 Full-duplex streaming is completely controlled by the server 232 application, and should only be enabled for clients that have been 233 explicitly identified by the server. 235 It is not sufficient to enable full-duplex HTTP solely based on User- 236 Agent. 238 For non-controlled client applications, the client needs advise its 239 capability of full-duplex streaming via URL parameters or headers 240 (for example, "X-Accept-Streaming: full-duplex;timeout=30"). 241 Otherwise, full-duplex streaming should be disabled, or the server 242 should return 404 (Not Found) status if full-duplex streaming is 243 mandatory for the requested resource. 245 4.2 Fall Back 247 Proxies may disallow early responses, or buffer requests or 248 responses. In such a case, the application may have to switch to a 249 different protocol that uses two connections and rely on polling 250 techniques. 252 One efficient way to trigger a fall back will be for the client to 253 wait for initial response for a short time-out period. Generally 254 there is no reliable way for a server to distinguish between ill- 255 behaved clients and non-compatible proxies. 257 4.3 Buffering 259 Full-duplex HTTP expects minimized buffering from both client and 260 server. However, applications may choose to buffer a certain amount 261 of streaming data for optimization or application specific purpose. 263 4.4 Messaging 265 Since chunked transfer-encoding isn't a reliable way to provide 266 message framing, messaging support has to be provided by the 267 application stack, along with any required delivery guarantees. 269 5 Security Considerations 271 Full-duplex HTTP introduces no new security concerns beyond those 272 known with regular HTTP communication. 274 6 IANA Considerations 276 This document does not require any actions by the IANA. 278 7 Acknowledgments 280 Thanks to Henrik Nordstrom, Jamie Lokier, and Mark Nottingham for 281 their feedback when the subject of this document was originally 282 brought up on httpbis. 284 8 Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 290 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 291 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 293 Author's Addresses 295 Wenbo Zhu 296 Google, Inc. 297 1600 Amphitheatre Parkway 298 Mountain View, CA 94043 299 US 301 Phone: +1 650 214 5894 302 Email: wenboz@google.com 304 Mike Jennings 306 Email: mike.c.jennings@gmail.com