idnits 2.17.1 draft-nottingham-http-roles-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 7) being 60 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (1 September 1999) is 9002 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) -- Missing reference section? '1' on line 44 looks like a reference -- Missing reference section? '2' on line 47 looks like a reference -- Missing reference section? '3' on line 55 looks like a reference -- Missing reference section? '4' on line 58 looks like a reference -- Missing reference section? '5' on line 81 looks like a reference -- Missing reference section? '6' on line 243 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Nottingham 2 Document: draft-nottingham-http-roles-00.txt 1 September 1999 3 Expires: 1 March 2000 5 Server-Side Roles in the HTTP 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. Internet-Drafts are draft documents valid for a maximum of 16 six months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Please send comments to Mark Nottingham 29 1. Abstract 31 Web servers are becoming more complex, and as a result are losing 32 the full benefits of HTTP protocol compliance. 34 This applicability statement defines classifications of Web server 35 sub-components and clarifies their responsibilities in implementing 36 HTTP/1.1 protocol features, with a discussion of the motivations for 37 doing so. 39 2. Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in RFC-2119 [1]. 45 3. Introduction 47 Although many Web servers available claim HTTP/1.1 [2] compliance, 48 the majority do not issue compliant responses for every object 49 served. This is especially noticeable for the performance-enhancing 51 Nottingham Expires 1 March 2000 1 52 Server-Side Roles in the HTTP August 1999 54 provisions of the protocol, such as persistent connections, transfer 55 encoding, and object validation [3]. 57 This behavior is most evident in objects which are created by non- 58 traditional means [4]. Historically, the primary method of managing 59 Web content was by storing it in a filesystem as discrete files. Web 60 servers were designed to serve static files as efficiently as 61 possible, while still having important (and readily available) 62 metadata such as Last-Modified (for validation) and Content-length 63 (for persistent connections) available. 65 Dynamically generated content (such as CGI) was thought of as a 66 small portion of the total traffic, and relatively inconsequential 67 when optimizing performance. 69 This is no longer necessarily the case. CGI and other specialized 70 methods are being used to manage entire Web sites. The filesystem, 71 with its easily generated metadata, is being replaced by a software 72 layer that presents a much more opaque profile to the server. 74 In common practice, this lack of clear responsibility between server 75 components results in partial or no support for key protocol 76 features, leaving compliance in the hands of the content publisher. 78 Consequently, the performance benefits of HTTP/1.1 are unrealized 79 for an increasing portion of Web traffic. Research has established 80 that they are both able to be realized and feasible to implement 81 [5]. 83 Additionally, future protocol extensions may not be useable for a 84 large number of entities generated by a server, for the same 85 reasons. 87 4. Goals 89 The goals of this document are to: 91 1. Define the roles and responsibilities of server-side components, 92 with respect to implementing HTTP/1.1 protocol features. 94 2. Promote interoperability of Web servers and increase the protocol 95 compliance of objects served, without to regard to how they are 96 generated. 98 3. Prevent the burdening of content publishers with the 99 responsibility for protocol compliance by shifting responsibility to 100 the server, making the HTTP implementation transparent. 102 Nottingham Internet-Draft - Expires 1 March 2000 2 103 Server-Side Roles in the HTTP August 1999 105 5. Terminology 107 HTTP/1.1 defines two primary roles implicitly: 109 client 110 A program that establishes connections for the purpose of 111 sending requests. 113 server 114 An application program that accepts connections in order to 115 service requests by sending back responses. Any given program 116 may be capable of being both a client and a server; our use of 117 these terms refers only to the role being performed by the 118 program for a particular connection, rather than to the 119 program's capabilities in general. Likewise, any server may act 120 as an origin server, proxy, gateway, or tunnel, switching 121 behavior based on the nature of each request. 123 In this document, server means the component of the software that 124 actually responds to the request. Also, we only consider generalized 125 servers; that is, those that are capable of serving content for a 126 number of purposes. Single-purpose (e.g., embedded) servers are out 127 of scope. 129 Additional roles, such as proxy, gateway and tunnel, are defined, 130 but are considered out of scope for this proposal. 132 The following terms are new: 134 content 135 The intended entity-body payload. It may or may not be actually 136 transferred in a response. 138 content generator 139 A means by which requests are mapped to content, which is 140 optionally transformed, generated or otherwise prepared, and 141 then passed back to the server, which then sends it to the 142 client. The generator may be, but is not necessarily, external 143 to the server. 145 publisher 146 A person or persons who make content available on the server, 147 possibly through a content generator. 149 synthetic validator 150 A validator generated by a server, without knowledge of the 151 process used to produce the content it describes. 153 Nottingham Internet-Draft - Expires 1 March 2000 3 154 Server-Side Roles in the HTTP August 1999 156 6. Server Role and Responsibilities 158 Implementation of HTTP protocol features should, in general, be the 159 responsibility of the server. A server SHOULD NOT expect a content 160 generator, content management system or publisher to handle them, 161 except where it does not have sufficient information available to do 162 so. 164 Core features of interest are listed below; this is not meant to be 165 exhaustive, but only an indication of those most critical and 166 obvious. 168 6.1 Persistent Connections 170 Servers MUST support a persistent connection if the content 171 generator supplies a Content-Length header. If it is not available, 172 the server SHOULD attempt to buffer the response in order to 173 generate one, although this MAY be circumvented if: 174 * the server does not have resources (i.e., memory) to do so, or 175 * the object is very large, and overall latency becomes 176 unacceptable, or 177 * the time required to generate the object adds unacceptable latency 179 Because many clients begin rendering HTML as soon as it is 180 available, servers MAY reduce size and time thresholds for text/html 181 responses. 183 There MUST be a method by which content generators can specify that 184 content is not to be buffered; this MAY be performed by a pseudo- 185 HTTP header that is consumed by the server. 187 Servers MUST serve chunked encoding responses for all objects, if: 188 * Content-Length is unavailable and impractical to generate 189 and 190 * the client advertises itself as HTTP/1.1 capable, or 191 * the client includes 'chunked' in a TE header 193 6.2 Validators and Validation 195 Servers MUST pass through any validator (e.g., Etag or Last-Modified 196 date) sent by a Content Generator, without modification. 198 Conditional request validation MUST be handled by regenerating the 199 object, comparing the validators, and returning an appropriate 200 response. Servers MAY use an alternate method of regenerating the 201 validator without generating the entire object, if the validator 202 produced is equivalent. 204 6.2.1 Synthetic Validators 206 Servers SHOULD generate synthetic validators for objects that do not 207 any associated, when possible. However, this MUST NOT be done when 208 the generated object contains a Cache-Control: no-store header. 210 Nottingham Internet-Draft - Expires 1 March 2000 4 211 Server-Side Roles in the HTTP August 1999 213 Synthetic validators MUST be strong, and MUST have a Cache-Control: 214 no-cache and Expires time in the past associated, unless a freshness 215 period is explicitly assigned. 217 One possible method of synthetic validator generation would be to 218 chunk-encode or buffer the response (as outlined above) and append a 219 Trailer containing the MD5 hash of the body as a validator. 221 6.3 Partial Content 223 Servers MUST respond to partial-content requests (i.e., those with 224 Range headers) appropriately, by using the Content Generator to 225 produce the response, and then sending back the requested range(s). 227 6.4 Transfer-Encoding 229 Servers SHOULD reply to requests that allow transfer encoding of 230 objects (i.e., TE header present) with appropriate encoding, in a 231 fashion transparent to the content generator. 233 6.5 HEAD Requests 235 HEAD requests SHOULD be responded to by using the content generator 236 to produce a GET response, omitting the body before returning it to 237 the client. 239 6.5 Publisher Access 241 Servers SHOULD provide a suitable method of setting per-object and 242 global metadata (such as Expires times and Cache-Control headers) to 243 users. If WebDAV [6] is implemented, it MAY be the mechanism used. 245 7. Content Generator Role and Responsibilities 247 Content generators SHOULD provide as much information as possible to 248 the server, to facilitate efficient operation. This includes 249 Content-Length, Etag and/or Last-Modified validators, and freshness 250 information, as possible. 252 Content generators SHOULD NOT specify unique URLs for multiple 253 instances of identical content, if avoidable. When this does happen 254 predictably, the generator SHOULD include a Cache-Control: no-store 255 header. 257 User-specific or transaction-based content SHOULD have an associated 258 Cache-Control: no-store header, unless there is a possibility of 259 reuse of the resource (by one or more clients), and side effects of 260 the transaction are not important. 262 Content generators SHOULD allow publishers to specify that buffering 263 is not to be used for specific content. 265 Nottingham Internet-Draft - Expires 1 March 2000 5 266 Server-Side Roles in the HTTP August 1999 268 8. Security Considerations 270 There are no security implications specific to this document; see 271 the HTTP/1.1 security section for general information. 273 9. References 275 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 276 Levels", BCP 14, RFC 2119, March 1997 277 2 Fielding, R. et al., "Hypertext Transfer Protocol - HTTP/1.1", 278 RFC2616, June, 1999 279 3 Krishnamurthy, B., Arlitt, M., "PRO-COW: Protocol Compliance on 280 the Web", AT&T Labs - Research Technical Report # 990803-05-TM 281 4 Nottingham, M., "Web Server Capabilities", 282 http://www.mnot.net/papers/capabilities.html 283 5 Wills, C., Mikhailov, M., "Examining the Cacheability of User- 284 Requested Web Resources", 4th Web Caching Workshop, San Diego CA, 285 March 1999 286 6 Whitehead, E. et al., "HTTP Extensions for Distributed Authoring 287 - WEBDAV", RFC2518, February 1999 289 10. Acknowledgments 291 The author would like to thank Mike Ciavarella for his constructive 292 comments. 294 11. Author's Addresses 296 Mark Nottingham 297 Email: mnot@pobox.com 299 Nottingham Internet-Draft - Expires 1 March 2000 6 300 Server-Side Roles in the HTTP August 1999 302 Full Copyright Statement 304 "Copyright (C) The Internet Society (1999). All Rights Reserved. 305 This document and translations of it may be copied and furnished to 306 others, and derivative works that comment on or otherwise explain it 307 or assist in its implementation may be prepared, copied, published 308 and distributed, in whole or in part, without restriction of any 309 kind, provided that the above copyright notice and this paragraph 310 are included on all such copies and derivative works. However, this 311 document itself may not be modified in any way, such as by removing 312 the copyright notice or references to the Internet Society or other 313 Internet organizations, except as needed for the purpose of 314 developing Internet standards in which case the procedures for 315 copyrights defined in the Internet Standards process must be 316 followed, or as required to translate it into languages other than 317 English. 319 The limited permissions granted above are perpetual and will not be 320 revoked by the Internet Society or its successors or assigns. 322 This document and the information contained herein is provided on an 323 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 324 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 325 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 326 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 327 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 329 Nottingham Internet-Draft - Expires 1 March 2000 7