2004/id/draft-lawrence-http-noclock-00.txt


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.

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