idnits 2.17.1 draft-ietf-http-ses-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 487 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '6' is mentioned on line 229, but not defined == Unused Reference: '4' is defined on line 457, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-http-v10-spec is -04, but you're referring to -05. ** Downref: Normative reference to an Informational draft: draft-ietf-http-v10-spec (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-http-v11-spec-01 == Outdated reference: A later version (-06) exists of draft-ietf-wts-shttp-01 ** Downref: Normative reference to an Historic draft: draft-ietf-wts-shttp (ref. '4') -- No information found for draft-freier-ssl-version3 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group Alexander Hopmann 2 INTERNET-DRAFT ResNova Software, Inc. 3 4 Expires SIX MONTHS FROM---> February 21st, 1996 6 Persistent HTTP Connections 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To learn the current status of any Internet-Draft, please check 22 the "1id-abstracts.txt" listing contained in the Internet- 23 Drafts Shadow Directories on ds.internic.net (US East Coast), 24 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 25 munnari.oz.au (Pacific Rim). 27 Distribution of this document is unlimited. Please send comments 28 to the HTTP working group at . 29 Discussions of the working group are archived at 30 . General discussions 31 about HTTP and the applications which use HTTP should take place 32 on the mailing list. 34 This draft does not currently represent a consensus opinion of the 35 HTTP Working Group. 37 Abstract 39 HTTP was designed to be an extremely lightweight stateless protocol 40 based on TCP. However actual implementation experience suggests that 41 the overhead inherent in establishing a separate TCP connection for 42 every request represents a significant performance problem. This 43 proposal suggests an optional facility for HTTP version 1.1 which 44 allows a client to create persistent connections with a server. This 45 facility is also designed to work with proxy servers. 47 Table of Contents 49 1. Introduction 50 1.1 Purpose 51 1.2 Overall Operation 52 1.3 Proxy Servers 53 1.4 Sticky Headers 54 1.5 Compatibility with HTTP/1.0 55 1.6 Interaction With Security Protocols 56 1.7 Practical Considerations 57 2. Examples 58 3. Security Considerations 59 4. Acknowledgments 60 5. References 61 6. Author's Address 63 1. Introduction 65 1.1 Purpose 67 The HyperText Transfer Protocol's strongest point is its simplicity. 68 The creators of HTTP [1] made it stateless in order to simplify 69 server design and also make servers more efficient. However with 70 the extraordinary success of the World Wide Web, HTTP servers 71 are often overloaded. In addition, the use of inline images and other 72 associated data often requires a client to make multiple requests of 73 the same server in a short amount of time. HTTP usually runs on top 74 of TCP which has many performance limitations for short-lived 75 connections. Because of the way that HTTP works, these performance 76 problems can become quite serious. An excellent analysis of these 77 performance problems is available [2]. 79 This draft is being proposed as a component of HTTP version 1.1 [3]. 80 It is based on work being done by the HTTP working group of the IETF. 82 1.2 Overall Operation 84 HTTP version 1.1 provides a new request and response header field 85 called "Connection". This header field allows the client and server 86 to specify options which should only exist over that particular 87 connection and must not communicated by proxies over further 88 connections. The connection header field may have multiple tokens 89 separated by commas. HTTP version 1.1 proxies must parse this field 90 and for every value in this field, remove a header field of the same 91 name from the request. 93 When a client is connecting directly to an origin server it should 94 send the following: 96 Connection: persist 97 Persist: 99 The value is either a domain name for the origin 100 server in the IANA domain, or the IP address of the origin server in 101 dot form (a.b.c.d). The origin server must verify that this name 102 corresponds to it, or must not establish a persistent connection. 104 If the server agrees to create a persistent connection it will 105 respond with the same two header fields. Both the client and server 106 must send these two header fields with every request and response for 107 the duration of the persistent connection. If either the client or 108 the server omits the Persist header that request becomes the last one 109 for the connection. A server should not establish a persistent 110 connection with a HTTP/1.0 client that uses the above form of the 111 Persist header (See section 1.5 for more information on backwards 112 compatibility with HTTP 1.0 clients). 114 Once the client has received the first response from the server 115 containing the "Persist" header field, it may pipeline multiple 116 requests without waiting for the response from the previous ones. The 117 server must send all of the responses in the same order that the 118 requests were made. 120 When using persistent connections both the client and the server must 121 obey one of the following two rules in order to transmit an entity 122 body: 124 either 126 a) Send a content-length field in the header with the exact number of 127 bytes in the entity-body. 129 or 131 b) Send the message as Content-type: multipart/mixed (Or some other 132 multipart content type), with a boundary marker. The end of the 133 entity-body is specified by the exact ending of the ending 134 boundary. Although RFC 1521 (MIME part 1) specifies that 135 multipart/mixed messages may have an epilogue after the ending 136 boundary, this epilogue must not be present for clients and 137 servers using persistent connections. 139 1.3 Proxy Servers 141 When a client is connecting to a proxy server it must send an 142 expanded form of the persist header: 144 Connection: persist 145 persist: 147 The value is either a domain name for the proxy server 148 in the IANA domain, or the IP address of the proxy server in dot form 149 (a.b.c.d). 151 When the proxy server receives this request it must check the value and make sure that it corresponds to itself. The server 153 must choose some policy for determining if the proxy-name corresponds 154 to itself. For example if the proxy-name is a domain name a server 155 might do a domain-name lookup on that name and compare the returned 156 IP address to its own. If the proxy-name does not correspond to the 157 proxy, it must not establish a persistent connection. 159 The proxy server must negotiate persistent connections separately 160 with its clients and the origin servers (or other proxy servers) that 161 it connects to. Each persistent connection applies to only one 162 transport link. 164 In no case should a proxy ever establish a persistent connection with 165 an HTTP 1.0 client. 167 1.4 Sticky Headers 169 In order to further maximize performance a client and a server may 170 negotiate the use of sticky headers. Sticky headers can reduce the 171 amount of redundant information that has to be transmitted with every 172 request. 174 The negotiation of the sticky headers option must take place on the 175 first request of a persistent connection. The client may add the 176 token "sticky" to the Connection header. If the server accepts the 177 use of sticky headers, it responds with the same token in the 178 Connection header of its response. 180 When using sticky-headers, any values for the following header fields 181 are remembered from request to request: 183 accept, accept-charset, accept-language, accept-encoding, 184 authorization, proxy-authorization, from, host, user-agent. 186 When sticky-headers are being used, the server remembers the fields 187 from the previous requests. If the client specifies a different value 188 for a field in a request, the new value replaces the remembered 189 value. Therefore the server acts as if the actual content of the 190 fields of a request is the combination of the fields in the current 191 request, and the remembered fields. 193 If in any request the client does not include the "sticky" token in 194 the connection header, the server must not use its stored values for 195 the headers in interpreting the request. 197 However, once the "sticky" option has been negotiated any subsequent 198 request can contain the token. The server will then act as if the 199 actual content of that new request is the combination of the fields 200 in the current request and the fields of the previous request only. 201 As a consequence, a server must record the values of the headers in 202 each request, to be used in case the subsequent request specifies 203 sticky headers. 205 1.5 Compatibility with HTTP/1.0 207 Some clients and servers may wish to be compatible with some pervious 208 implementations of persistent connections in HTTP version 1.0 clients 209 and servers. 211 When connecting to an origin server an HTTP client may send the 212 following instead of that specified in section 1.2: 214 Connection: keep-alive,persist 215 Persist: 216 Keep-alive: 218 A client must not send the Keep-alive header field to a proxy server. 220 An HTTP/1.0 server would then respond with the Keep-Alive header field 221 and the client may proceed with a persistent connection. 223 An HTTP/1.1 server may receive a keep-alive header field. It may then 224 establish a persistent connection. 226 1.6 Interaction with Security Protocols 228 It is expected that the Session extension will operate with both 229 SHTTP [5] and SSL [6]. When used in conjunction with SHTTP the SHTTP 230 request is prepared normally, persistent connection headers in the 231 outermost request block (the one containing the "Secure" method). 232 When used in conjunction with SSL a SSL session is started as normal 233 and the first HTTP request made using SSL contains the persistent 234 connection header. 236 1.7 Practical Considerations 238 Servers will usually have some time-out value beyond which they will 239 no longer maintain an inactive connection. Proxy servers might make 240 this a higher value since it is likely that the client will be making 241 more connections through the same server. The use of persistent 242 connections places no requirements on the length of this time-out for 243 either the client or the server. 245 When a client or server wishes to time-out it should reset the 246 transport connection. 248 2. Examples 250 The first example shows a client connecting to a server, requesting 251 a session, and the server accepting. 252 NOTE: In all examples the notation represents two octets, CR 253 and LF. 255 client: 256 server: 258 client: 259 GET / HTTP/1.1 260 Accept: text/html 261 Accept: image/jpeg 262 Connection: persist 263 Persist: www.resnova.com 264 266 server: 267 HTTP/1.1 200 OK 268 MIME-Version: 1.0 269 Content-Type: text/html 270 Content-Length: 94 271 Connection: persist 272 Persist: www.resnova.com 273 274 275

This is a message

276 277 279 client: (has read 94 octets of entity-body) 280 GET /myimg.jpg HTTP/1.1 281 283 server: (using same accept: values as the first request) 284 HTTP/1.1 200 OK 285 MIME-Version: 1.0 286 Content-Type: image/jpeg 287 Content-Length: 1024 288 Connection: persist 289 Persist: www.resnova.com 290 291 <1024 octets of data here> 293 client: (has read 1024 octets of entity-body) 294 GET /somecgi.cgi HTTP/1.1 295 Connection: persist 296 Persist: www.resnova.com 297 299 server: (Note that the server is running a CGI and doesn't know its 300 expected size) 302 HTTP/1.1 200 OK 303 MIME-Version: 1.1 304 Content-Type: multipart/mixed; boundary="abcdefghijklmnop" 305 Connection: persist 306 Persist: www.resnova.com 307 308 --abcdefghijklmnop 309 Content-type: text/html 310 311 312

This is a message

313 314 315 --abcdefghijklmnop-- 317 client: (has read the after the ending boundary 318 320 server: 321 323 The second example is identical to the first except that the server 324 does not wish to establish a persistent connection. 326 client: 327 GET / HTTP/1.1 328 Accept: text/html 329 Accept: image/jpeg 330 Connection: persist 331 Persist: www.resnova.com 332 334 server: 335 HTTP/1.1 200 OK 336 MIME-Version: 1.0 337 Content-Type: text/html 338 Content-Length: 94 339 340 341

This is a message

342 343 345 346 (client did not receive the persist header so it knows to identify 347 the end of the body by the connection close). 349 The third example demonstrates the use of sticky headers. 351 client: 352 353 GET / HTTP/1.1 354 Accept: text/html 355 Accept-Language: en 356 Connection: persist,sticky 357 359 server: 360 HTTP/1.1 200 OK 361 MIME-Version: 1.0 362 Connection: persist,sticky 363 Content-Type: text/html 364 Content-Length:94 365 366 <94 bytes body data here> 368 client: 369 (client makes a request changing the Accept value but maintaining the 370 value of the Accept-Language: field from the previous request) 372 GET /myimg.jpg HTTP/1.1 373 Accept: image/jpeg 374 Connection: persist,sticky 375 377 server: 378 HTTP/1.1 200 OK 379 MIME-Version: 1.0 380 Connection: persist,sticky 381 Content-Type: image/jpeg 382 Content-Length:4000 383 384 <4000 bytes body data here> 386 client: 387 (client makes a non-sticky request) 388 GET /something.html HTTP/1.1 389 Accept: text/html 390 Accept-Language: x-pig-latin 391 Connection: persist 392 394 server: 395 HTTP/1.1 200 OK 396 MIME-Version: 1.0 397 Connection: persist 398 Content-Type: text/html 399 Content-Length:106 400 401 <106 bytes body data here> 403 client: 404 (client another sticky request) 405 GET /more.html HTTP/1.1 406 Connection: persist,sticky 407 409 server: 410 HTTP/1.1 200 OK 411 MIME-Version: 1.0 412 Connection: persist,sticky 413 Content-Type: text/html 414 Content-Length:164 415 416 <164 bytes body data here> 418 3. Security 420 This HTTP extension has two indirect effects on security. Using 421 sticky headers can reduce the performance penalty of authentication, 422 since a client can send one authentication header and 423 maintain that authentication for a period of time. On the other hand 424 an attacker could theoretically intercept a previously initiated 425 communication channel and substitute itself, gaining the 426 authentication attributes of the client that initiated the 427 communication. This latter attack could only work with the non-secure 428 authentication methods anyway so it is not considered to be a serious 429 concern by the author. 431 4. Acknowledgments 433 The key contributors to the Persistent HTTP Connection effort include 434 Roy T. Fielding (UCI), Alan Freier (Netscape), Jeff Mogul(DEC), Lou 435 Montulli (Netscape), Paul Leach (Microsoft), Simon Spero (EIT), Andy 436 Norman (HP), and Scott Powers (NCSA). Other contributors include 437 Allan M. Schiffman (Terisa Systems), Greg Herlihy (ResNova Software), 438 and Tim Berners-Lee (W3O). 440 5 References 442 [1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. 443 "HyperText Transfer Protocol -- HTTP/1.0" 444 Internet-Draft (work in progress), UC Irvine, 445 , February 19, 1996. 448 [2] S. Spero. "Analysis of HTTP Performance Problems" 449 451 [3] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen. 452 "HyperText Transfer Protocol -- HTTP/1.1" 453 Internet-Draft (work in progress), UC Irvine, 454 , January 19, 1996. 457 [4] E. Rescorla, A. Schiffman 458 "The Secure HyperText Transfer Protocol" 459 Internet-Draft (work in progress) 460 , February, 1996. 463 [5] A. Freier, P Karlton, P. Kocher. 464 "SSL Version 3.0" 465 Internet- Draft (work in progress) 466 , December, 1995. 469 6 Author's Address 471 Alex Hopmann 472 alex.hopmann@resnova.com 473 President 474 ResNova Software, Inc. 475 5011 Argosy Dr. #13 476 Huntington Beach, CA 92649