Network Working Group R. Fielding Request for Comments: 2616 ...

An example isDate: Tue, 15 Nov 1994 08:12:31 GMTOrigin servers MUST include a Date header field in all responses,except in these cases:Fielding, et al. Standards Track [Page 124]RFC 2616 HTTP/1.1 June 19991. If the response status code is 100 (Continue) or 101 (SwitchingProtocols), the response MAY include a Date header field, atthe server's option.2. If the response status code conveys a server error, e.g. 500(Internal Server Error) or 503 (Service Unavailable), and it isinconvenient or impossible to generate a valid Date.3. If the server does not have a clock that can provide areasonable approximation of the current time, its responsesMUST NOT include a Date header field. In this case, the rulesin section 14.18.1 MUST be followed.A received message that does not have a Date header field MUST beassigned one by the recipient if the message will be cached by thatrecipient or gatewayed via a protocol which requires a Date. An HTTPimplementation without a clock MUST NOT cache responses withoutrevalidating them on every use. An HTTP cache, especially a sharedcache, SHOULD use a mechanism, such as NTP [28], to synchronize itsclock with a reliable external standard.Clients SHOULD only send a Date header field in messages that includean entity-body, as in the case of the PUT and POST requests, and eventhen it is optional. A client without a clock MUST NOT send a Dateheader field in a request.The HTTP-date sent in a Date header SHOULD NOT represent a date andtime subsequent to the generation of the message. It SHOULD representthe best available approximation of the date and time of messagegeneration, unless the implementation has no means of generating areasonably accurate date and time. In theory, the date ought torepresent the moment just before the entity is generated. Inpractice, the date can be generated at any time during the messageorigination without affecting its semantic value.14.18.1 Clockless Origin Server Operation