What happens if the origin web server sets the expires value in response header as a time which is passed relatively long ago?

Question

What happens if the origin web server sets the expires value in response header as a time which is passed relatively long ago.

For instance, consider current time is Fri, 25 Jan 2013 GMT, and the expire header is set as -->

Expires: Thu, 01 Dec 1994 16:00:00 GMT

How will the client respond for the above instance?

Any help would be appreciated

Answer 1

Responding with a past date in the Expired header (earlier than the Date header value) makes no sense and would be a sign of some serious misconfiguration. That being said, clients would treat such response as "already expired" and not cache it. Same applies if Expires date is equal to Date header value (which is the correct way of server marking the response as "already expired") or having an invalid format.

See the Expires section of RFC 2616 for details.

Answer 2

An expire time pointing to a specific and fixed date in the past is often seen in relatively poor configs and/or relatively poor (starters) code whereby the intent is to prevent the HTTP 1.1 client to cache the response. This will work, but a specific and fixed date in the past is plain ridiculous. A value of 0 would make more sense, or a value exactly equal to the Date response header, which is less often seen, but recommended by the HTTP Expires header specification, cited below (emphasis mine):

...

HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").

To mark a response as "already expired," an origin server sends an Expires date that is equal to the Date header value. (See the rules for expiration calculations in section 13.2.4.)

...

See also:

• How to control web page caching, across all browsers? - you'll see that some of the lower rated answers mention a specific and fixed date in the past, which just evidences ignorance.