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

with appropriate error status. The server MUST respond with a 417(Expectation Failed) status if any of the expectations cannot be metor, if there are other problems with the request, some other 4xxstatus.This header field is defined with extensible syntax to allow forfuture extensions. If a server receives a request containing anExpect field that includes an expectation-extension that it does notsupport, it MUST respond with a 417 (Expectation Failed) status.Comparison of expectation values is case-insensitive for unquotedtokens (including the 100-continue token), and is case-sensitive forquoted-string expectation-extensions.Fielding, et al. Standards Track [Page 126]RFC 2616 HTTP/1.1 June 1999The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUSTreturn a 417 (Expectation Failed) status if it receives a requestwith an expectation that it cannot meet. However, the Expectrequest-header itself is end-to-end; it MUST be forwarded if therequest is forwarded.Many older HTTP/1.0 and HTTP/1.1 applications do not understand theExpect header.See section 8.2.3 for the use of the 100 (continue) status.14.21 ExpiresThe Expires entity-header field gives the date/time after which theresponse is considered stale. A stale cache entry may not normally bereturned by a cache (either a proxy cache or a user agent cache)unless it is first validated with the origin server (or with anintermediate cache that has a fresh copy of the entity). See section13.2 for further discussion of the expiration model.The presence of an Expires field does not imply that the originalresource will change or cease to exist at, before, or after thattime.The format is an absolute date and time as defined by HTTP-date insection 3.3.1; it MUST be in RFC 1123 date format: