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
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.
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.)
...
From RFC 7234:
If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past to
indicate that the response is already stale.
This makes clear that it is a valid behaviour, and that a client should treat the response as stale and validate it on every subsequent call.
