idnits 2.17.1 draft-loreto-http-timeout-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No 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 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 9, 2010) is 5060 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-09 == Outdated reference: A later version (-07) exists of draft-loreto-http-bidirectional-02 ** Downref: Normative reference to an Informational draft: draft-loreto-http-bidirectional (ref. 'I-D.loreto-http-bidirectional') ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HYBI S. Loreto 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Thomson 5 Expires: December 11, 2010 Andrew Corporation 6 G. Wilkins 7 Webtide 8 June 9, 2010 10 Hypertext Transfer Protocol (HTTP) Timeouts 11 draft-loreto-http-timeout-00 13 Abstract 15 A Timeout header is defined for Hypertext Transfer Protocol (HTTP). 16 This end-to-end header informs an origin server and any 17 intermediaries of the maximum time that a client will await a 18 response to its request. A server can use this header to ensure that 19 a timely response is generated. This also identifies requests as 20 being potentially long-lived, and allows for better resource 21 allocation for these requests. 23 A Connection-Timeout header is defined for HTTP. This hop-by-hop 24 header informs the entity at the other end of a connection of the 25 maximum time that an idle connection is kept open. This header 26 improves reliability by providing better information about the idle 27 connection management policy of HTTP hosts. 29 Comments and feedback for this draft should be directed to the 30 authors and the Apps Discuss list (discuss@apps.ietf.org). 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 11, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Request Timeouts . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Idle Connection Timeouts . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Timeout Header . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Existing Intermediaries . . . . . . . . . . . . . . . . . 5 72 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Connection-Timeout Header . . . . . . . . . . . . . . . . . . 7 74 4.1. Existing Intermediaries . . . . . . . . . . . . . . . . . 8 75 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Timeout HTTP header Registration . . . . . . . . . . . . . 10 79 6.2. Connection-Timeout HTTP header Registration . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 7.2. Normative References . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 This document describes two headers that provide Hypertext Transfer 88 Protocol (HTTP) [RFC2616] hosts with timing information. 90 The "Timeout" header describes the time available for a single HTTP 91 request. 93 The "Connection-Timeout" header describes the time that an idle 94 connection is retained. 96 1.1. Request Timeouts 98 HTTP is a client-driven protocol. As such, a server is only able to 99 provide information to a client when that client requests it. To 100 address the need for servers to provide low-latency notifications to 101 clients, a practice of long-polling [I-D.loreto-http-bidirectional] 102 is commonplace. 104 Long-polling requires that a client maintain an open request to a 105 server. The server withholds responses to this request until the 106 event of interest occurs. The open request provides the server with 107 a way to send a message immediately after the event occurs. After 108 the response containing the notification is received, the client 109 immediately opens another open request. 111 Long-polling differs significantly to many HTTP requests, which do 112 not have significant delay between request and response. Long- 113 polling requests monopolize a connection for the time that they are 114 outstanding. For this reason, it is useful for a server or 115 intermediary to identify a long-polling request. Identifying a long- 116 polling request would enable specialized resource management for 117 long-polling requests; for instance, separate connection allocations 118 and management, longer timeout periods and long-poll optimizations. 120 A connection that is used for long-polling also appears to be idle 121 for a significant period. Management of idle connections can 122 interfere with the operation of a long-poll. Many intermediaries 123 legitimately use timeouts to avoid clients from monopolizing the use 124 of outgoing connections. If an intermediary times out a request, the 125 server is unable to send a response. 127 Knowing the time available to provide a response can avoid problems 128 with timeouts. Current implementations select times between 30 and 129 120 seconds, times that have been empirically determined to be safe. 130 A server provides a null response before this time to ensure that the 131 connection appears to be active to intermediaries. Such low values 132 are potentially wasteful, since each null response and subsequent 133 request generates traffic. A null response can also increase the 134 latency of notifications, since the response removes the channel that 135 the server would use for notifications. 137 The Timeout header defined in Section 3 describes the maximum time 138 available to a server in providing a response to any particular 139 request. 141 For the Timeout header, Section 3.1 includes a discussion of the 142 interaction with existing HTTP intermediaries and other 143 intermediaries like network address translation (NAT) device. 145 [[Open: Any value in echoing the actual value back to a client? MT: 146 inclined to say no: we need a _use_, other than pure information, 147 there's already a mechanism for ensuring that server gets the right 148 value, having the client update its value is of no great benefit, 149 especially since that encourages use of dodgy heuristics (i.e., is 150 this request going to the same place?)]] 152 1.2. Idle Connection Timeouts 154 Management of idle HTTP connections has an impact on long-lived 155 communications between hosts. Hosts are able to close idle 156 connections in order to reduce resource consumption. 158 Many clients choose not to send non-idempotent requests on idle 159 connections. If the intermediary or server holding the other end of 160 the connection chooses to close the connection while a non-idempotent 161 request is in transit, the client has no way to tell if the request 162 has succeeded. For this reason, many clients establish a new 163 connection for every non-idempotent request. This is inefficient if 164 the existing connection is usable connection: establishing a new 165 connection adds significantly to the latency of the request. 167 Polling of resource state can more efficiently use connection 168 resources when an idle connection timeout is known. A client that 169 polls on an interval that is close to the connection timeout can 170 ensure that polling requests are made before the idle connection is 171 closed, avoiding any need to retry a request due to the 172 aforementioned problem. Alternatively, a client that knows that the 173 connection timeout is less than the polling interval can close the 174 connection immediately after a poll, releasing resources. 176 A Connection-Timeout header is defined in Section 4. This hop-by-hop 177 header informs hosts of the minumum time that a connection remains 178 idle before it is closed. Indicating this time explicitly gives a 179 client the knowledge necessary to reuse an idle connection with a 180 greater assurance that the connection is usable. 182 2. Terminology 184 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 185 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 186 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 187 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 188 levels for compliant implementations. 190 3. Timeout Header 192 The "Timeout" header is a end-to-end request header that indicates 193 the maximum time that a client is prepared to await a response. 195 Timeout = "Timeout" ":" timeout-value 196 timeout-value = 1*DIGIT 198 A client adds a Timeout header to any request for which they are 199 prepared to await a response. The client sets the header to the 200 maximum time that they are prepared to wait. 202 The value of the Timeout header is a single integer value in seconds. 204 An origin server interprets this header as the time between receipt 205 of a complete request and the time that it generates and begins 206 sending the response. A client will observe a longer time interval 207 between request and response, as network transit and processing by 208 intermediaries add delays. If this time is critical, a client SHOULD 209 allow for delays in setting a value for the header. 211 An origin server MAY apply a lower value to the timeout based on 212 local policy. An origin server MAY choose to take longer to produce 213 a response, at the risk that the client is no longer able to use the 214 response. 216 An HTTP intermediary MAY reduce the value of a Timeout header based 217 on local policy. An intermediary MAY add a Timeout header if none is 218 present. The value in the Timeout header MUST NOT be increased or 219 removed. 221 The client MUST NOT set the value of the Timeout header greater than 222 the value of the Connection-Timeout header. 224 3.1. Existing Intermediaries 226 The exact impact of an intermediary on an HTTP request with a Timeout 227 header depends on the type of intermediary. 229 An intermediary that is compliant with HTTP/1.1 passes this header, 230 but unaware of the header semantics, passes the header on to the 231 origin server without altering it. For an intermediary that does not 232 time out requests, or an intermediary that has a timeout period that 233 is longer than the one specified in the header, this has no impact. 235 An existing intermediary that has a shorter timeout period than the 236 indicated time will time out a request before the server generates a 237 response. The intermediary could send the client a 504 (Gateway 238 Timeout) response when it times out. 240 An intermediary that forwards requests without altering them (a 241 transparent intermediary) is similar to an HTTP/1.1 compliant 242 intermediary. 244 A non-compliant intermediary might remove a Timeout header. This 245 means that the server is unaware of the timeliness requirements of 246 the client. A server that expects a Timeout header can attempt to 247 guess an appropriate value. 249 A network address translation (NAT) device might interact with 250 timeouts. These devices maintain state about TCP connections that 251 are established through them. This state can be discarded or lost if 252 the connection remains idle. A NAT device failure can also cause 253 state loss. Further attempts to use the connection either fail 254 without error, or result in the NAT device sending a TCP "RST" to the 255 entity that attempts to use the connection. 257 A client MAY revise the Timeout header that it sends in subsequent 258 requests to the same resource or origin server if it detects 259 intermediaries or NAT devices that have shorter timeout periods. 260 However, two requests are not guaranteed to follow the same path 261 through a network, especially for different resources. A client that 262 employs a heuristic for setting the Timeout header SHOULD ensure that 263 any knowledge it obtains about timeouts is not retained indefinitely. 265 3.2. Examples 267 The following example shows how a Timeout header could be used. In 268 this case, both intermediaries - proxy and gateway - both reduce the 269 timeout based on their policy. 271 Client Proxy Gateway Server 272 | | | | 273 +-- Timeout: 300 -->| | | 274 | +-- Timeout: 250 -->| | 275 | | +-- Timeout: 240 -->| 276 | | | ^ | 277 . . . | . 278 . . . up to 240 seconds 279 . . . | . 280 | | | V | 281 | | |<----- 200 OK -----+ 282 | |<----- 200 OK -----+ | 283 |<----- 200 OK -----+ | | 284 | | | | 286 4. Connection-Timeout Header 288 The "Connection-Timeout" header is a hop-by-hop header that indicates 289 the minimum time that an idle connection will be maintained. 291 Connection-Timeout = "Connection-Timeout" ":" timeout-value 292 ; timeout-value from Timeout header 294 This header is sent by either host participating in a persistent 295 connection. A host sets the value to the minimum time that local 296 policy at that host allows for an idle connection to remain open. A 297 connection is idle if no data is sent or received by a host. 299 The value of the Connection-Timeout header is a single integer in 300 seconds. 302 As a hop-by-hop header, this header only applies to a single 303 transport-level connection. If a Connection-Timeout header is added 304 to a request or response, the Connection header MUST include the tag 305 "Connection-Timeout". This ensures that intermediaries that do not 306 recognize this header remove it before forwarding a request. 308 A host MAY keep an idle connection open for longer than the time that 309 it indicates, but it SHOULD attempt to retain a connection for at 310 least as long as indicated. 312 Network transit and processing by intermediaries add additional 313 delays that can skew the subjective perception of whether a 314 connection is idle. A client SHOULD make allowances for any delays 315 in determining whether to reuse an idle connection. 317 An intermediary that provides a Connection-Timeout header value, MUST 318 set the value of the Timeout header in any requests that it forwards 319 to be less than or equal to the Connection-Timeout that it provides. 321 4.1. Existing Intermediaries 323 The exact impact of an intermediary on an HTTP request with a 324 Connection-Timeout header depends on the type of intermediary. 326 An intermediary that is compliant with HTTP/1.1 ignores and discards 327 this header before forwarding a request. Since it is unaware of the 328 semantics of the header it could drop an idle connection at any time 329 (see Section 7.1.4 of [I-D.ietf-httpbis-p1-messaging]). 331 A non-compliant or otherwise transparent intermediary might pass this 332 header on to the next hop. This results in same types of errors that 333 the Keep-Alive header causes, as described in Section 19.7.1 of 334 [RFC2068]. 336 A network address translation (NAT) device might cause a connection 337 to become unavailable prior to the advertised timeout. 339 A host MAY revise the Connection-Timeout header that it sends in 340 subsequent requests to the same resource or origin server if it 341 detects intermediaries or NAT devices that have shorter timeout 342 periods. 344 4.2. Example 346 The following example shows how a Connection-Timeout header could be 347 used. All connections are independently negotiated. In this 348 example, the client indicates a timeout of 600 seconds (10 minutes), 349 but the proxy is only prepared to retain the connection for at least 350 120 seconds (2 minutes). On the link between proxy and server, the 351 proxy requests a timeout of 1200 seconds and the server reduces this 352 to 300 seconds. 354 Client Proxy Server 355 | | | 356 +- Connection-Timeout: 600 -->| | 357 | Connection: | | 358 | Connection-Timeout | | 359 | +- Connection-Timeout: 1200 -->| 360 | | Connection: | 361 | | Connection-Timeout | 362 | | | 363 | |<-- Connection-Timeout: 300 --+ 364 | | Connection: | 365 | | Connection-Timeout | 366 |<-- Connection-Timeout: 120 -+ | 367 | Connection: | | 368 | Connection-Timeout | | 369 | | | 371 5. Security Considerations 373 Establishing a persistent connection requires a commitment of 374 resources at a host. The Timeout and Connection-Timeout headers are 375 used to express host policy that could alter the way that a host 376 allocates connection resources. 378 A host that alters its policies based on the receipt of either header 379 could be exploited by a malicious host to either benefit from 380 increased access to resources or to consume resources in the hopes of 381 depriving another host. 383 An attacker might attempt to keep a connection from becoming idle, to 384 keep the connection open. A client could legitimately do this to 385 benefit from a reduced latency for later requests, but an attacker 386 might exploit this to monopolize server resources. A host that has 387 indicated a Connection-Timeout MAY close a non-idle connection sooner 388 than the indicated time if necessary or dictated by local policy (see 389 Section 7.1.4 of [I-D.ietf-httpbis-p1-messaging]). 391 6. IANA Considerations 393 This section registers the two HTTP headers in the "Permanent Message 394 Header Fields" registry established by [RFC3864]. 396 [[Note to IANA/RFC Editor: Please replace instance of RFCXXXX with 397 the number of the published RFC and remove this note.]] 399 6.1. Timeout HTTP header Registration 401 This document registers the HTTP "Timeout" header in the "Permanent 402 Message Header Fields" registry established by [RFC3864] 404 Header field: Timeout 406 Applicable protocol: HTTP 408 Status: standard 410 Author/change controller: Internet Engineering Task Force, IETF 411 (iesg@ietf.org) 413 Specification document(s): RFCXXXX (this document) 415 6.2. Connection-Timeout HTTP header Registration 417 This document registers the HTTP "Connection-Timeout" header in the 418 "Permanent Message Header Fields" registry established by [RFC3864] 420 Header field: Connection-Timeout 422 Applicable protocol: HTTP 424 Status: standard 426 Author/change controller: Internet Engineering Task Force, IETF 427 (iesg@ietf.org) 429 Specification document(s): RFCXXXX (this document) 431 7. References 433 7.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 439 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 440 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 442 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 443 Procedures for Message Header Fields", BCP 90, RFC 3864, 444 September 2004. 446 7.2. Normative References 448 [I-D.ietf-httpbis-p1-messaging] 449 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 450 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 451 "HTTP/1.1, part 1: URIs, Connections, and Message 452 Parsing", draft-ietf-httpbis-p1-messaging-09 (work in 453 progress), March 2010. 455 [I-D.loreto-http-bidirectional] 456 Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 457 "Best Practices for the Use of Long Polling and Streaming 458 in Bidirectional HTTP", draft-loreto-http-bidirectional-02 459 (work in progress), February 2010. 461 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 462 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 463 RFC 2068, January 1997. 465 Authors' Addresses 467 Salvatore Loreto 468 Ericsson 469 Hirsalantie 11 470 Jorvas 02420 471 Finland 473 Email: salvatore.loreto@ericsson.com 475 Martin Thomson 476 Andrew Corporation 477 Andrew Building (39) 478 Wollongong University Campus 479 Northfields Avenue 480 Wollongong, NSW 2522 481 AU 483 Phone: +61 2 4221 2915 484 Email: martin.thomson@andrew.com 485 Greg Wilkins 486 Webtide 488 Email: gregw@webtide.com