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
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