W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Origin Servers without Clocks

From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 22 Apr 1997 15:16:45 -0400
Message-Id: <199704221916.PAA15285@devnix.agranat.com>
To: HTTP Working Group List <http-wg@cuckoo.hpl.hp.com>

  I've just submitted the following to the I-D repository as:

    draft-lawrence-http-noclock-00.txt

  At the Memphis meeting, I briefly discussed the fact that many
  systems where our 1.1 server implementation will be used do not (and
  will not) have clocks, so sending the Date header is problematic.

  This draft attempts to address this issue.

  Much thanks to Jeff and Richard for helping put this together; any
  obvious mistakes are probably mine in preparing the final edits.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/


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[28], 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:  lawrence@agranat.com

   Jeffrey Mogul
      Western Research Laboratory
      Digital Equipment Corporation
      250 University Avenue
      Palo Alto, California, 94305, USA
   Email:  mogul@wrl.dec.com

   Richard Gray
      International Business Machines Corp.
      4205 S. Miami Blvd.
      RTP, NC 27709
   Email:  rlgray@raleigh.ibm.com

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.
Received on Tuesday, 22 April 1997 12:25:47 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:35 EDT