Internet Draft Scott Lawrence draft-lawrence-http-noclock-00.txt Agranat Systems, Inc. Expires: October 1997 Jeffrey Mogul Digital Equipment Corp. Richard Gray International Business Machines Corp. April 22, 1997 HTTP/1.1 Operation without a Clock Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This memo describes a problem with the current Proposed Standard for HTTP/1.1 found as a result of implementation experience. A web server may be implemented in an embedded system as a network user interface. Often the embedded system is one which has no other use for a real-time clock, and/or the web interface is being added to an existing device which has no clock. Without a clock, no accurate HTTP Date header can be generated. This memo examines the implications of this situation for the operation of HTTP/1.1 origin servers, proxies, and clients, and proposes changes to the HTTP/1.1 specification to permit compliant operation in such systems. draft-lawrence-http-noclock-00.txt Page 2/5 2. Background Web browsers provide a powerful set of user interface primitives, which are rapidly being applied to a wide range of applications; the browser has become a de-facto network user interface standard. One area of such application is the embedded system: a computer system built into a device that serves some purpose other than just being a computer. Including a clock in an embedded system design both adds cost and requires that the clock be accurately set, adding system complexity. For many embedded systems, a clock is not otherwise required, and many existing embedded systems that are otherwise capable of providing a web interface do not have a clock. The HTTP/1.1 Proposed Standard requires that an origin server always include a Date header ([RFC 2068], section 14.19). This requirement was strengthened from a SHOULD in the HTTP/1.0 specification to a MUST in the HTTP/1.1 specification, apparently in order to support the correct operation of caching both in proxies and clients. The HTTP/1.1 Proposed Standard specifies a number of headers for mechanisms to affect the operation of caches, including: - Date - Last-Modified - Expires - Cache-Control - Etag it also documents usage of the 'Pragma: no-cache' header for backward compatible cache control with some pre-HTTP/1.1 implementations. An important characteristic of an embedded web server implementation is that the content of such a server is well defined at the time the system is built, and each potential response is either: - A Static response, which changes only when the firmware of the system is changed. Examples include: pages of help information, cosmetic elements, and external links to the manufacturers web site. - A Dynamic response, which may change on any access. Examples include: pages which include information on the current state of the device. It is desirable that Static responses be cachable, and that Dynamic responses never be cached. The authors' contention here is that this can be achieved by correct usage of the other headers already specified by HTTP/1.1, without the requirement that the Date header always be sent by origin servers. draft-lawrence-http-noclock-00.txt Page 3/5 3. Proposed Change for HTTP/1.1 Requirements Section 14.19 of [RFC 2068] be replaced with (delimited by the '=' lines): ================ 14.19 Date The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in section 3.3.1. Date = "Date" ":" HTTP-date An example is Date: Tue, 15 Nov 1994 08:12:31 GMT Origin servers MUST include a Date header field in all responses, except in these cases: 1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response SHOULD NOT include a Date header field. 2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date. 3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.19.1 MUST be followed. A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date. An HTTP implementation without a clock MUST NOT cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, SHOULD use a mechanism, such as NTP, to synchronize its clock with a reliable external standard. Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request. ================ draft-lawrence-http-noclock-00.txt Page 4/5 The following subsection should be added: ================ 14.19.1 Clockless Origin Server Operation Some origin server implementations may not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource). ================ Section 10.3.5 ("304 Not Modified"), after: The response MUST include the following header fields: Replace o Date with o Date, unless its omission is required by section 14.19.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly. draft-lawrence-http-noclock-00.txt Page 5/5 4. Security Considerations The Date header is not an important part of any security mechanism; it is a component of the entity digest specified by [RFC 2069], but that document already specifies the behavior for all parties when no Date header is supplied. The author believes that the proposed changes have no security implications. 5. Author's Addresses Scott Lawrence Agranat Systems, Inc. 1345 Main St. Waltham, MA 02154 Phone: +1-617-893-7868 Fax: +1-617-893-5740 Email: firstname.lastname@example.org Jeffrey Mogul Western Research Laboratory Digital Equipment Corporation 250 University Avenue Palo Alto, California, 94305, USA Email: email@example.com Richard Gray International Business Machines Corp. 4205 S. Miami Blvd. RTP, NC 27709 Email: firstname.lastname@example.org 6. References [RFC 2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068, U.C. Irvine, DEC, MIT/LCS, January 1997. [RFC 2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP : Digest Access Authentication" RFC 2069, Northwestern University, CERN, Spyglass Inc., Microsoft Corp., Netscape Communications Corp., Spyglass Inc., Open Market Inc., January 1997.