idnits 2.17.1 draft-loreto-http-bidirectional-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (Feb 23, 2010) is 5175 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-08 -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Loreto 3 Internet-Draft Ericsson 4 Intended status: Informational P. Saint-Andre 5 Expires: August 27, 2010 Cisco 6 S. Salsano 7 Univ. of Rome "Tor Vergata" 8 G. Wilkins 9 Webtide 10 Feb 23, 2010 12 Best Practices for the Use of Long Polling and Streaming in 13 Bidirectional HTTP 14 draft-loreto-http-bidirectional-02 16 Abstract 18 There is widespread interest in using the Hypertext Transfer Protocol 19 (HTTP) to enable asynchronous or server-initiated communication from 20 a server to a client as well as from a client to a server. This 21 document describes how to better use HTTP, as it exists today, to 22 enable such "bidirectional HTTP" using "long polling" and "HTTP 23 streaming" mechanisms. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 27, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Long Polling . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Long Polling Issues . . . . . . . . . . . . . . . . . . . 5 68 3. HTTP Streaming . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. HTTP Streaming Issues . . . . . . . . . . . . . . . . . . 8 71 4. Overview of Technologies . . . . . . . . . . . . . . . . . . . 9 72 4.1. Bayeux . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2. BOSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.3. Server-Sent Events . . . . . . . . . . . . . . . . . . . . 12 75 5. HTTP Best Practices . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Two Connection Limit . . . . . . . . . . . . . . . . . . . 12 77 5.2. Pipelined Connections . . . . . . . . . . . . . . . . . . 13 78 5.3. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.4. HTTP Responses . . . . . . . . . . . . . . . . . . . . . . 14 80 5.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.6. Impact on intermediary entities . . . . . . . . . . . . . 15 82 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 10. Informative References . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 The Hypertext Transfer Protocol [HTTP-1.1] is a request/response 92 protocol. HTTP defines the following entities: clients, proxies, and 93 servers. A client establishes connections to a server for the 94 purpose of sending HTTP requests. A server accepts connections from 95 clients in order to service HTTP requests by sending back responses. 96 Proxies are intermediate entities that can be involved in the 97 delivery of requests and responses from the client to the server and 98 vice versa. 100 In the standard HTTP model, a server cannot initiate a connection 101 with a client nor send an unrequested HTTP response to the client; 102 thus the server cannot push asynchronous events to clients. 103 Therefore, in order to receive asynchronous events as soon as 104 possible, the client needs to poll the server periodically for new 105 content. However, continual polling can consume significant 106 bandwidth by forcing a request/response round trip when no data is 107 available. It can also be inefficient because it reduces the 108 responsiveness of the application since data is queued until the 109 server receives the next poll request from the client. 111 To improve this situation, several server push programming mechanisms 112 have been implemented in recent years. These mechanisms, which are 113 often grouped under the common label "Comet" [COMET], enable a web 114 server to send updates to clients without waiting for a poll request 115 from the client. Such mechanisms can deliver updates to clients in a 116 more timely manner while avoiding the latency experienced by client 117 applications due to the frequent open and close connections necessary 118 to periodically poll for data. 120 The two most common server push mechanisms are "Long Polling" and 121 "HTTP Streaming": 123 Long Polling: The server attempts to "hold open" (not immediately 124 reply to) each HTTP request, responding only when there are events 125 to deliver. In this way, there is always a pending request 126 available to use for delivering events as they occur, thereby 127 minimizing the latency in message delivery. 129 HTTP Streaming: The server keeps a request open indefinitely; that 130 is, it never terminates the request or closes the connection, even 131 after it pushes data to the client. 133 It is possible to define other technologies for bidirectional HTTP, 134 however such technologies typically require changes to HTTP itself 135 (e.g., by defining new HTTP methods). This document focuses only on 136 bidirectional HTTP technologies that work within the current scope of 137 HTTP as defined in [HTTP-1.1] and [HTTP-1.0]. 139 The remainder of this document is organized as follows. Section 2 140 analyzes the "long polling" technique. Section 3 analyzes the "HTTP 141 streaming" technique. Section 4 provides an overview of the specific 142 technologies that use server-push technique. Section 5 lists best 143 practices for bidirectional HTTP using existing technologies. 145 The preferred venue for discussion of this document is the 146 apps-discuss@ietf.org; visit 147 for further 148 information. 150 2. Long Polling 152 2.1. Definition 154 With the traditional or "short" polling technique, a client sends 155 regular requests to the server and each request attempts to "pull" 156 any available events or data. If there are no events or data 157 available, the server returns an empty response and the client waits 158 for a period before sending another poll request. The frequency 159 depends on the latency which can be tolerated in retrieving updated 160 information from the server. This mechanism has the drawback that 161 the consumed resources (server processing and network) strongly 162 depend on the acceptable latency in the delivery of updates from 163 server to client. If the acceptable latency is low (e.g., on the 164 order of seconds) then the frequency of the poll request can cause an 165 unacceptable burden on the server, the network, or both. 167 By contrast with such "short polling", "long polling" attempts to 168 minimize both latency in server-client message delivery and the 169 processing/network resource as compared to normal polling techniques. 170 The server achieves these efficiencies by responding to a request 171 only when a particular event, status, or timeout has occurred. Once 172 the server sends a long poll response, typically the client 173 immediately sends a new long poll request. Effectively this means 174 that at any given time the server will be holding open a long poll 175 request, to which it replies when new information is available for 176 the client. As a result, the server is able to asynchronously 177 "initiate" communication. 179 The basic life cycle of an application using "long polling" is as 180 follows: 182 1. The client makes an initial request and then waits for a 183 response. 185 2. The server defers its response until an update is available, or a 186 particular status or timeout has occurred. 188 3. When an update is available, the server sends a complete response 189 to the client. 191 4. The client typically sends a new long poll request, either 192 immediately or after a pause to allow an acceptable latency 193 period. 195 The long polling mechanism can be applied to either persistent or 196 non-persistent HTTP connections. The use of persistent HTTP 197 connections will avoid the additional overhead of establishing a 198 TCP/IP connection for every long poll. 200 2.2. Long Polling Issues 202 The long polling mechanism introduces the following issues. 204 Header Overhead: With the long polling technique, every long poll 205 request and long poll response is a complete HTTP message and thus 206 contains a full set of HTTP headers in the message framing. For 207 small infrequent messages, the headers can represent a large 208 percentage of the data transmitted. This does not introduce 209 significant technical issues if the network MTU allows all the 210 information (including the HTTP header) to fit within a single IP 211 packet. On the other hand, it can introduce business issues 212 related to data cost, as the amount of transferred data can be 213 significantly larger than the real payload carried by HTTP. 215 Maximal Latency: After a long polling response is sent to a client, 216 the server must wait for the next long polling request before 217 another message can be sent to the client. This means that while 218 the average latency of long polling is close to one network 219 transit, the maximal latency is over three network transits (long 220 poll response, next long poll request, long poll response). 221 However, because HTTP is carried on TCP/IP, packet loss and 222 retransmission can occur, so maximal latency for any TCP/IP 223 protocol will be more than three network transits (lost packet, 224 next packet, negative ack, retransmit). 226 Connection Establishment: A common criticism of both short polling 227 and long polling is that these mechanisms frequently open TCP/IP 228 connections and then close them. However, both polling mechanisms 229 work well with persistent HTTP connections that can be reused for 230 many poll requests. Specifically, the short duration of the pause 231 between a long poll response and the next long poll request avoids 232 the closing of idle connections. 234 Allocated Resources: Operating systems and network appliances will 235 allocate resources to TCP/IP connections and to HTTP requests 236 outstanding on those requests. The long polling mechanism 237 requires that for each client, both a TCP/IP connection and an 238 HTTP request are held open. Thus it is important to consider the 239 resources related to both of these when sizing a long polling 240 application. Typically the resources used per TCP/IP connection 241 are minimal and can scale reasonably. Frequently the resources 242 allocated to HTTP requests can be significant, and scaling the 243 total number of requests outstanding can be limited on some 244 gateways, proxies, and servers. 246 Graceful Degradation: A long polling client or server that is under 247 load has a natural tendency to gracefully degrade in performance 248 at a cost of message latency. If load causes either a client or 249 server to run slowly, then events to be pushed to clients will 250 queue (waiting either for a long poll request or for available CPU 251 to use a held long poll request). If multiple messages are queued 252 for a client, then they may be delivered in a batch within a 253 single long poll response. This can significantly reduce the per- 254 message overhead and thus ease the work load of the client or 255 server for the given message load. 257 3. HTTP Streaming 259 3.1. Definition 261 The "HTTP streaming" mechanism keeps a request open indefinitely. It 262 never terminates the request or closes the connection, even after the 263 server pushes data to the client. This mechanism significantly 264 reduces the network latency because the client and the server do not 265 need to open and close the connection. 267 The basic life cycle of an application using "HTTP streaming" is as 268 follows: 270 1. The client makes an initial request and then waits for a 271 response. 273 2. The server defers the response to a poll request until an update 274 is available, or a particular status or timeout has occurred. 276 3. Whenever an update is available, the server sends it back to the 277 client as a part of the response. 279 4. The data sent by the server does not terminate the request or the 280 connection. The server returns to step 3. 282 The HTTP streaming mechanism is based on the capability of the server 283 to send several pieces of information on the same response, without 284 terminating the request or the connection. This result can be 285 achieved by both HTTP/1.1 and HTTP/1.0 servers. 287 A HTTP response content length can be defined using 3 options: 289 Content-Length header: This indicates the size of the entity body in 290 the message, in bytes. 292 Transfer-Encoding header: The 'chunked' valued in this header 293 indicates the message will be break into chunks of known size. 295 End of File (EOF): This is actually the default approach for 296 HTTP/1.0 where the connections are not persistent. Clients do not 297 need to know the size of the body they are reading; instead they 298 expect to read the body until the server closes the connection. 299 Although with HTTP/1.1 the default is for persistent connections, 300 it still possible to use EOF by setting the 'Connection:close' 301 header in either the request or the response, to indicate that the 302 connection should not be considered 'persistent' after the current 303 request/response is complete. The client's inclusion of the 304 'Connection: close' header field in the request will also prevent 305 pipelining. 307 The main issue with EOF is that it is difficult to tell the 308 difference between a connection terminated by a fault and one that 309 is correctly terminated. 311 An HTTP/1.0 server can use only EOF as a streaming mechanism. By 312 contrast, both EOF and "chunked transfer" are available to an 313 HTTP/1.1 server. 315 The "chunked transfer" mechanism is the one typically used by 316 HTTP/1.1 servers for streaming. It does so by including the header 317 "Transfer-Encoding: chunked" at the beginning of the response, which 318 enables it to send the following parts of the response in different 319 "chunks" over the same connection. Each chunk starts with the 320 hexadecimal expression of the length of its data, followed by CR/LF 321 (the end of the response is indicated with a chunk of size 0). 323 HTTP/1.1 200 OK 324 Content-Type: text/plain 325 Transfer-Encoding: chunked 327 25 328 This is the data in the first chunk 330 1C 331 and this is the second one 333 0 335 Figure 1: Transfer-Encoding response 337 A HTTP/1.0 server will omit the Content-Length header in the response 338 to achieve the same result, so it will be able to send the following 339 parts of the response on the same connection (in this case the 340 different parts of the response are not explicitly separated by HTTP 341 protocol, and the end of the response is achieved by closing the 342 connection). 344 3.2. HTTP Streaming Issues 346 The HTTP streaming mechanism introduces the following issues. 348 Network Intermediaries: The HTTP protocol allows for intermediaries 349 (proxies, transparent proxies, gateways, etc.) to be involved in 350 the transmission of a response from server to the client. There 351 is no requirement for an intermediary to immediately forward a 352 partial response and it is legal for it to buffer the entire 353 response before sending any data to the client (e.g., caching 354 transparent proxies). HTTP streaming will not work with such 355 intermediaries. 357 Maximal Latency: Theoretically, on a perfect network, an HTTP 358 streaming protocol's average and maximal latency is one network 359 transit. However, in practice the maximal latency is higher due 360 to network and browser limitations. The browser techniques used 361 to terminate HTTP streaming connections are often associated with 362 JavaScript and/or DOM elements that will grow in size for every 363 message received. Thus in order to avoid unlimited memory growth 364 in the client, an HTTP streaming implementation must occasionally 365 terminate the streaming response and send a request to initiate a 366 new streaming response (which is essentially equivalent to a long 367 poll). Thus the maximal latency is at least three network 368 transits. Also, because HTTP is carried on TCP/IP, packet loss 369 and retransmission can occur, so maximal latency for any TCP/IP 370 protocol will be more than three network transits (lost packet, 371 next packet, negative ack, retransmit). 373 Client Buffering: There is no requirement in existing HTTP 374 specifications for a client library to make the data from a 375 partial HTTP response available to the client application. For 376 example, if each response chunk contains a statement of 377 JavaScript, there is no requirement in the browser to execute that 378 JavaScript before the entire response is received. However, in 379 practice most browsers do execute JavaScript received in partial 380 responses, but some require a buffer overflow to trigger 381 execution, so blocks of white space can be sent to achieve buffer 382 overflow. 384 Framing Techniques: Using HTTP streaming, several application 385 messages can be sent within a single HTTP response. The 386 separation of the response stream into application messages needs 387 to be perfomed at the application level and not at the HTTP level. 388 In particular it is not possible to use the HTTP chunks as 389 application message delimiters, since intermediate proxies might 390 "re-chunk" the message stream (for example by combining different 391 chunks into a longer one). This issue does not affect the long 392 polling technique, which provides a canonical framing technique: 393 each application message can be sent in a different HTTP response. 395 4. Overview of Technologies 397 This section provides an overview of how the specific technologies 398 that implement server-push mechanisms employ HTTP to asynchronously 399 deliver messages from the server to the client. 401 4.1. Bayeux 403 The Bayeux protocol [BAYEUX] was developed in 2006-2007 by the Dojo 404 Foundation. Bayeux can use both the long polling and HTTP streaming 405 mechanisms. 407 In order to achieve bidirectional communications, a Bayeux client 408 will use two HTTP connections to a Bayeux server so that both server- 409 to-client and client-to-server messaging can occur asynchronously. 411 The Bayeux specification requires that implementations control 412 pipeling of HTTP requests, so that requests are not pipelined 413 inappropriately (e.g., a client-to-server message pipelined behind a 414 long poll request). 416 In practice, for JavaScript clients, such control over pipelining is 417 not possible in current browsers. Therefore JavaScript 418 implementations of Bayeux attempt to meet this requirement by 419 limiting themselves to a maximum of two outstanding HTTP requests at 420 any one time, so that browser connection limits will not be applied 421 and the requests will not be queued or pipelined. While broadly 422 effective, this mechanism can be disrupted by non-Bayeux JavaScript 423 simultaneously issuing requests to the same host. 425 Bayeux connections are negotiated between client and server with 426 handshake messages that allow the connection type, authentication 427 method, and other parameters to be agreed upon between the client and 428 the server. Furthermore, during the handshake phase, the client and 429 the server reveal to each other their acceptable bidirectional 430 techniques and the client selects one from the intersection of those 431 sets. 433 For non-browser or same-domain Bayeux, clients use HTTP POST requests 434 to the server for both the long poll request and the request to send 435 messages to the server. The Bayeux protocol packets are sent as the 436 body of the HTTP messages using the "text/json; charset=utf-8" MIME 437 content type. 439 For browsers that are operating in cross-domain mode, Bayeux clients 440 use the "script src Ajax" ("AJAST") mechanism as described at 441 . 443 Client-to-server messages are sent as encoded JSON on the URL query 444 parameters. 446 Server-to-client messages are sent as a JavaScript program that wraps 447 the message JSON with a JavaScript function call to the already 448 loaded Bayeux implementation. 450 4.2. BOSH 452 BOSH, which stands for Bidirectional-streams Over Synchronous HTTP 453 [BOSH], was developed by the XMPP Standards Foundation in 2003-2004. 454 The purpose of BOSH is to emulate normal TCP connections over HTTP 455 (TCP is the standard connection mechanism used in the Extensible 456 Messaging and Presence Protocol as described in [XMPP]). BOSH 457 employs the long polling mechanism by allowing the server (called a 458 "BOSH connection manager") to defer its response to a request until 459 it actually has data to send to the client from the application 460 server itself (typically an XMPP server). As soon as the client 461 receives a response from the connection manager, it sends another 462 request to the connection manager, thereby ensuring that the 463 connection manager is (almost) always holding a request that it can 464 use to "push" data to the client. 466 In some situations, the client needs to send data to the server while 467 it is waiting for data to be pushed from the connection manager. To 468 prevent data from being pipelined behind the long poll request that 469 is on hold, the client can send its outbound data in a second HTTP 470 request. BOSH forces the server to respond to the request it has 471 been holding on the first connection as soon as it receives a new 472 request from the client, even if it has no data to send to the 473 client. It does so to make sure that the client can send more data 474 immediately if necessary even in the case where the client is not 475 able to pipeline the requests, respecting at the same time the two- 476 connection limit discussed here under Section 5.1. 478 The number of long polling request-response pairs is negotiated 479 during the first request sent from the client to the connection 480 manager. Typically BOSH clients and connection managers will 481 negotiate the use of two pairs, although it is possible to use only 482 one pair or to use more than two pairs. 484 The roles of the two response-response pairs typically switch 485 whenever the client sends data to the connection manager. This means 486 that when the client issues a new request, the connection manager 487 immediately answers to the blocked request on the other TCP 488 connection, thus freeing it; in this way, in a scenario where only 489 the client sends data, all the even requests are sent over one 490 connection and the odd ones are sent over the other connection. 492 BOSH is able to work reliably both when network conditions force 493 every HTTP request to be made over a different TCP connection and 494 when it is possible to use HTTP/1.1 and then relay on two persistent 495 TCP connections. 497 If the connection manager has no data to send to the client for an 498 agreed amount of time (also negotiated during the first request), 499 then the connection manager will respond to the request it has been 500 holding with no data, and that response immediately triggers a fresh 501 client request. The connection manager does so to ensure that if a 502 network connection is broken then both parties will realise that fact 503 within a reasonable amount of time. 505 Moreover BOSH defines the negotiation of an "inactivity period" value 506 that specifies the longest allowable inactivity period (in seconds). 507 This enables the client to ensure that the periods with no requests 508 pending are never too long. 510 BOSH allows data to be pushed immediately when HTTP Pipelining is 511 available. However if HTTP Pipelining is not available and one of 512 the endpoints has just pushed some data, BOSH will usually need to 513 wait for a network round trip time until it is able to push again. 515 BOSH uses standard HTTP POST request and response bodies to encode 516 all information. 518 BOSH normally uses HTTP Pipelining over a persistent HTTP/1.1 519 connection. However, a client can deliver its POST requests in any 520 way permitted by HTTP 1.0 or HTTP 1.1. 522 BOSH clients and connection managers are not allowed to use Chunked 523 Transfer Coding, since intermediaries might buffer each partial HTTP 524 request or response and only forward the full request or response 525 once it is available. 527 BOSH allows the usage of the Accept-Encoding and Content-Encoding 528 headers in the request and in the response respectively, and then 529 compresses the response body accordingly. 531 Each BOSH session can share the HTTP connection(s) it uses with other 532 HTTP traffic, including other BOSH sessions and HTTP requests and 533 responses completely unrelated to the BOSH protocol (e.g., web page 534 downloads). 536 4.3. Server-Sent Events 538 W3C Server-Sent Events specification [W3C.WD-eventsource-20090423] 539 defines an API that enables servers to push data to Web pages over 540 HTTP in the form of DOM events. 542 The data is encoded as text/event-stream content and pushed using a 543 HTTP streaming mechanism, but the specification suggests to disable 544 HTTP chunking for serving event streams unless the rate of messages 545 is high enough to avoid the possible negative effects of this 546 technique as described here under Section 3.2. 548 However it is not clear the benefit of using EOF rather than chunking 549 with regards to intermediaries, unless they are HTTP/1.0. 551 5. HTTP Best Practices 553 5.1. Two Connection Limit 555 HTTP [HTTP-1.1] section 8.1.4 specified that a single user client 556 should not maintain more than two connections to any server or proxy, 557 to prevent the server from being overloaded and to avoid unexpected 558 side effects in congested networks. The new specification 559 [I-D.ietf-httpbis-p1-messaging] removes the limitation, encouraging 560 clients to be conservative when opening multiple connections. 562 Web applications need to limit the number of long poll requests 563 initiated, ideally to a single long poll that is shared between 564 frames, tabs, or windows of the same browser. However the security 565 constraints of the browsers make such sharing difficult. 567 A possible best practice is for a server to use cookies to detect 568 multiple long poll requests from the same browser and to avoid 569 deferring both requests since this might cause connection starvation 570 and/or pipeline issues. 572 5.2. Pipelined Connections 574 HTTP [HTTP-1.1] permits optional request pipelining over persistent 575 connections. Multiple requests can be enqueued before the responses 576 arrive. 578 There is a possible open issue regarding the inability to control 579 "pipelining". Normal requests can be pipelined behind a long poll, 580 and are thus delayed until the long poll completes. 582 5.3. Proxies 584 Most proxies work well with long polling, because a complete HTTP 585 response must be sent either on an event or a timeout. Proxies 586 should return that response immediately to the user-agent, which 587 immediately acts on it. 589 The HTTP streaming mechanism uses partial responses and sends some 590 JavaScript in an HTTP/1.1 chunk as described under Section 3. This 591 mechanism can face problems caused by two factors: (1) it relies on 592 proxies to forward each chunk (even though there is no requirement 593 for them to do so, and some caching proxies do not), and (2) it 594 relies on user-agents to execute the chunk of JavaScript as it 595 arrives (even though there is also no requirement for them to do so). 597 A "reverse proxy" basically is a proxy that pretends to be the actual 598 server (as far as any client or client proxy is concerned), but it 599 passes on the request to the actual server that is usually sitting 600 behind another layer of firewalls. Any short polling or long polling 601 Comet solution should work fine with this, as will most streaming 602 Comet connections. The main downside is performance, since most 603 proxies are not designed to hold many open connections (as a 604 dedicated Comet server is). 606 Reverse proxies can come to grief when they try to share connections 607 to the servers between multiple clients. As an example, Apache with 608 mod_jk shares a small set of connections (often 8 or 16) between all 609 clients. If long polls are sent on those shared connections, then 610 the proxy can be starved of connections, which means that other 611 requests (either long poll or normal) can be held up. Thus Comet 612 mechanisms currently need to avoid any connection sharing -- either 613 in the browser or in any intermediary -- because the HTTP assumption 614 is that each request will complete as fast as possible. 616 Much of the "badness" of both long polling and HTTP streaming for 617 servers and proxies results from using a synchronous programming 618 model for handling requests, since the resources allocated to each 619 request are held for the duration of the request. Asynchronous 620 proxies and servers can handle Comet long polls with few resources 621 above that of normal HTTP traffic. Unfortunately some synchronous 622 proxies do exist (e.g., apache mod_jk) and many HTTP application 623 servers also have a blocking model for their request handling (e.g., 624 the Java servlet 2.5 specification). 626 5.4. HTTP Responses 628 The server responds to a request successfully received by sending a 629 200 OK answer, but only when a particular event, status, or timeout 630 has occurred. The 200 OK body section contains the actual event, 631 status, or timeout that occurred. 633 5.5. Timeouts 635 The long polling mechanism allows the server to respond to a request 636 only when a particular event, status, or timeout has occurred. In 637 order to minimize as much as possible both latency in server-client 638 message delivery and the processing/network resources needed, the 639 long polling request timeout should be set to a high value. 641 However, the value timeout value has to be chosen carefully; indeed, 642 there can be problem if this value is set too high (e.g., the client 643 might receive a 408 Request Timeout answer from the server or a 504 644 Gateway Timeout answer from a proxy). The default timeout value in a 645 browser is 300 seconds, but most network infrastructures have proxies 646 and server that do not have such a long timeout. 648 Several experiments have shown success with timeouts as high as 120 649 seconds, but generally 30 seconds is a safer value. Therefore it is 650 recommended that all network equipment wishing to be compatible with 651 the long polling mechanism should implement a timeout substantially 652 greater than 30 seconds (where "substantially" means several times 653 more than the medium network transit time). 655 5.6. Impact on intermediary entities 657 There is no way for an end client or host to give HTTP intermediaries 658 the hints that long-polling is in use, therefore long-poll requests 659 are completely transparent for intermediary entities and are handled 660 as normal requests. This may have an impact for intermediary 661 entities that perform operations that are not useful in case of long- 662 polling. However any capabilities that may interfere with 663 bidirectional flow (e.g. caching) can be controlled with standard 664 headers or cookies. 666 The caching is always intentionally suppressed in a long-poll request 667 or response: the "Cache-Control" header is set to "no-cache". 669 OPEN ISSUE 1: Any experience on different headers or on the usage of 670 cookies? 672 OPEN ISSUE 2: Any well known impact on Firewall(s) and NATs? 674 6. Future Work 676 This document focuses on best practices for bidirectional HTTP in the 677 context of HTTP as it exists today. Future documents might define 678 additions to HTTP that could enable improved mechanisms for 679 bidirectional HTTP. Examples include: 681 o An HTTP extension for long polling, including request tracking, 682 duplication, and retry methods. 684 o A method for monitoring the state of multiple resources. 686 o A request header to determine timeouts. 688 o A request header to determine the longest acceptable polling 689 interval. 691 o Improved rendezvous logic between the user agent, a proxy / 692 connection manager, and the backend application server. 694 o Improved addressing for the entities involved in bidirectional 695 HTTP, possibly including the use of URI templates. 697 o Possible improvements/extensions to XMLHttpRequest (XHR) API 698 [W3C.WD-XMLHttpRequest2-20090820] to expose connection-handling 699 details (e.g., use of pconns, pipelining, etc.) 701 7. Acknowledgments 703 Thanks to Joe Hildebrand, Mark Nottingham, Martin Thomson and Martin 704 Tyler for their feedback. 706 8. IANA Considerations 708 This document does not require any actions by the IANA. 710 9. Security Considerations 712 This document is meant to describe current usage of http to enable 713 asynchronous or server-initiated communication. It does not propose 714 any change to the http protocol or to the expexted behaviour of http 715 entities. Therefore this document does not introduce new security 716 concerns into existing http infrastructure. 718 OPEN ISSUE 3: the number of open connections in long polling and http 719 streaming could more easily lead to DOS attacks [RFC4732]. 721 OPEN ISSUE 4: a possible slight security concern with cross site long 722 polling is related to the fact that often it is implemented by 723 executing the javascript returned from the long-poll request. If the 724 server is prone to an injection attacks, then it could be far easier 725 to trick a browser into executing the code [W3C.WD-cors-20090317]. 727 10. Informative References 729 [BAYEUX] Russell, A., Wilkins, G., Davis, D., and M. Nesbitt, 730 "Bidirectional-streams Over Synchronous HTTP (BOSH)", 731 2007. 733 [BOSH] Paterson, I., Smith, D., and P. Saint-Andre, 734 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 735 XEP 0124, February 2007. 737 [COMET] Russell, A., "Comet: Low Latency Data for the Browser", 738 March 2006. 740 [HTTP-1.0] 741 Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 742 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 744 [HTTP-1.1] 745 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 746 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 747 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 749 [I-D.ietf-httpbis-p1-messaging] 750 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 751 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 752 "HTTP/1.1, part 1: URIs, Connections, and Message 753 Parsing", draft-ietf-httpbis-p1-messaging-08 (work in 754 progress), October 2009. 756 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 757 Service Considerations", RFC 4732, December 2006. 759 [W3C.WD-XMLHttpRequest2-20090820] 760 Kesteren, A., "XMLHttpRequest Level 2", World Wide Web 761 Consortium WD WD-XMLHttpRequest2-20090820, August 2009, 762 . 764 [W3C.WD-cors-20090317] 765 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 766 Web Consortium WD WD-cors-20090317, March 2009, 767 . 769 [W3C.WD-eventsource-20090423] 770 Hickson, I., "Server-Sent Events", World Wide Web 771 Consortium WD WD-eventsource-20090423, April 2009, 772 . 774 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 775 Protocol (XMPP): Core", RFC 3920, October 2004. 777 Authors' Addresses 779 Salvatore Loreto 780 Ericsson 781 Hirsalantie 11 782 Jorvas 02420 783 Finland 785 Email: salvatore.loreto@ericsson.com 787 Peter Saint-Andre 788 Cisco 790 Email: psaintan@cisco.com 791 Stefano Salsano 792 Univ. of Rome "Tor Vergata" 793 Via del Politecnico, 1 794 Rome 00133 795 Italy 797 Email: stefano.salsano@uniroma2.it 799 Greg Wilkins 800 Webtide 802 Email: gregw@webtide.com