- From: Scott Lawrence <lawrence@agranat.com>
- Date: Tue, 22 Apr 1997 15:16:45 -0400
- 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 UTC