idnits 2.17.1 draft-lawrence-http-noclock-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 are 11 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 62: '...engthened from a SHOULD in the HTTP/1....' RFC 2119 keyword, line 63: '...ecification to a MUST in the HTTP/1.1 ...' RFC 2119 keyword, line 121: '... Origin servers MUST include a Date h...' RFC 2119 keyword, line 124: '...ng Protocols), the response SHOULD NOT...' RFC 2119 keyword, line 132: '... MUST NOT include a Date header fie...' (9 more instances...) 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.) -- The document date (April 22, 1997) is 9859 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) -- Looks like a reference, but probably isn't: '28' on line 140 ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2069 (Obsoleted by RFC 2617) Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Scott Lawrence 2 draft-lawrence-http-noclock-00.txt Agranat Systems, Inc. 3 Expires: October 1997 Jeffrey Mogul 4 Digital Equipment Corp. 5 Richard Gray 6 International Business Machines Corp. 7 April 22, 1997 9 HTTP/1.1 Operation without a Clock 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 30 1. Abstract 32 This memo describes a problem with the current Proposed Standard 33 for HTTP/1.1 found as a result of implementation experience. A web 34 server may be implemented in an embedded system as a network user 35 interface. Often the embedded system is one which has no other use 36 for a real-time clock, and/or the web interface is being added to 37 an existing device which has no clock. Without a clock, no 38 accurate HTTP Date header can be generated. 40 This memo examines the implications of this situation for the 41 operation of HTTP/1.1 origin servers, proxies, and clients, and 42 proposes changes to the HTTP/1.1 specification to permit compliant 43 operation in such systems. 45 draft-lawrence-http-noclock-00.txt Page 2/5 47 2. Background 49 Web browsers provide a powerful set of user interface primitives, 50 which are rapidly being applied to a wide range of applications; 51 the browser has become a de-facto network user interface standard. 52 One area of such application is the embedded system: a computer 53 system built into a device that serves some purpose other than just 54 being a computer. Including a clock in an embedded system design 55 both adds cost and requires that the clock be accurately set, 56 adding system complexity. For many embedded systems, a clock is 57 not otherwise required, and many existing embedded systems that are 58 otherwise capable of providing a web interface do not have a clock. 60 The HTTP/1.1 Proposed Standard requires that an origin server 61 always include a Date header ([RFC 2068], section 14.19). This 62 requirement was strengthened from a SHOULD in the HTTP/1.0 63 specification to a MUST in the HTTP/1.1 specification, apparently 64 in order to support the correct operation of caching both in 65 proxies and clients. 67 The HTTP/1.1 Proposed Standard specifies a number of headers for 68 mechanisms to affect the operation of caches, including: 70 - Date 71 - Last-Modified 72 - Expires 73 - Cache-Control 74 - Etag 76 it also documents usage of the 'Pragma: no-cache' header for 77 backward compatible cache control with some pre-HTTP/1.1 78 implementations. 80 An important characteristic of an embedded web server 81 implementation is that the content of such a server is well defined 82 at the time the system is built, and each potential response is 83 either: 85 - A Static response, which changes only when the firmware of 86 the system is changed. 87 Examples include: pages of help information, cosmetic 88 elements, and external links to the manufacturers web site. 90 - A Dynamic response, which may change on any access. 91 Examples include: pages which include information on the 92 current state of the device. 94 It is desirable that Static responses be cachable, and that Dynamic 95 responses never be cached. The authors' contention here is that 96 this can be achieved by correct usage of the other headers already 97 specified by HTTP/1.1, without the requirement that the Date header 98 always be sent by origin servers. 100 draft-lawrence-http-noclock-00.txt Page 3/5 102 3. Proposed Change for HTTP/1.1 Requirements 104 Section 14.19 of [RFC 2068] be replaced with (delimited by the '=' 105 lines): 107 ================ 108 14.19 Date 110 The Date general-header field represents the date and time at which 111 the message was originated, having the same semantics as orig-date in 112 RFC 822. The field value is an HTTP-date, as described in section 113 3.3.1. 115 Date = "Date" ":" HTTP-date 117 An example is 119 Date: Tue, 15 Nov 1994 08:12:31 GMT 121 Origin servers MUST include a Date header field in all responses, 122 except in these cases: 123 1. If the response status code is 100 (Continue) or 124 101 (Switching Protocols), the response SHOULD NOT 125 include a Date header field. 126 2. If the response status code conveys a server error, 127 e.g. 500 (Internal Server Error) or 503 (Service Unavailable), 128 and it is inconvenient or impossible to generate a valid 129 Date. 130 3. If the server does not have a clock that can provide a 131 reasonable approximation of the current time, its responses 132 MUST NOT include a Date header field. In this case, the 133 rules in section 14.19.1 MUST be followed. 135 A received message that does not have a Date header field MUST be 136 assigned one by the recipient if the message will be cached by that 137 recipient or gatewayed via a protocol which requires a Date. An 138 HTTP implementation without a clock MUST NOT cache responses without 139 revalidating them on every use. An HTTP cache, especially a shared 140 cache, SHOULD use a mechanism, such as NTP[28], to synchronize its 141 clock with a reliable external standard. 143 Clients SHOULD only send a Date header field in messages that 144 include an entity-body, as in the case of the PUT and POST 145 requests, and even then it is optional. A client without a 146 clock MUST NOT send a Date header field in a request. 147 ================ 148 draft-lawrence-http-noclock-00.txt Page 4/5 150 The following subsection should be added: 152 ================ 153 14.19.1 Clockless Origin Server Operation 155 Some origin server implementations may not have a clock available. 156 An origin server without a clock MUST NOT assign Expires or 157 Last-Modified values to a response, unless these values were 158 associated with the resource by a system or user with a reliable 159 clock. It MAY assign an Expires value that is known, at or before 160 server configuration time, to be in the past (this allows 161 "pre-expiration" of responses without storing separate Expires 162 values for each resource). 163 ================ 165 Section 10.3.5 ("304 Not Modified"), after: 167 The response MUST include the following header fields: 169 Replace 171 o Date 173 with 175 o Date, unless its omission is required by section 14.19.1 177 If a clockless origin server obeys these rules, and proxies and 178 clients add their own Date to any response received without one (as 179 already specified by [RFC 2068], section 14.19), caches will 180 operate correctly. 182 draft-lawrence-http-noclock-00.txt Page 5/5 184 4. Security Considerations 186 The Date header is not an important part of any security mechanism; 187 it is a component of the entity digest specified by [RFC 2069], but 188 that document already specifies the behavior for all parties when no 189 Date header is supplied. 191 The author believes that the proposed changes have no security 192 implications. 194 5. Author's Addresses 196 Scott Lawrence 197 Agranat Systems, Inc. 198 1345 Main St. 199 Waltham, MA 02154 200 Phone: +1-617-893-7868 201 Fax: +1-617-893-5740 202 Email: lawrence@agranat.com 204 Jeffrey Mogul 205 Western Research Laboratory 206 Digital Equipment Corporation 207 250 University Avenue 208 Palo Alto, California, 94305, USA 209 Email: mogul@wrl.dec.com 211 Richard Gray 212 International Business Machines Corp. 213 4205 S. Miami Blvd. 214 RTP, NC 27709 215 Email: rlgray@raleigh.ibm.com 217 6. References 219 [RFC 2068] 220 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. 221 "Hypertext Transfer Protocol -- HTTP/1.1." 222 RFC 2068, 223 U.C. Irvine, DEC, MIT/LCS, 224 January 1997. 226 [RFC 2069] 227 J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, 228 A. Luotonen, E. Sink, and L. Stewart. 229 "An Extension to HTTP : Digest Access Authentication" 230 RFC 2069, 231 Northwestern University, CERN, Spyglass Inc., Microsoft Corp., 232 Netscape Communications Corp., Spyglass Inc., Open Market Inc., 233 January 1997.