Does this mean that the server MUST convert a non-GMT date value to GMT? Or does it mean that if (optionally) it chooses to convert a non-GMT date value to GMT (rather than rejecting it) then it MUST use the most conservative possible conversion?
This is really something that's more specific to the field in question than something that's applied generally. There is a working group draft that would obselete RFC 2616 that has this to say about conversion in caches:
- HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve the "year 2000" problem).
- Although all date formats are specified to be case-sensitive, recipients SHOULD match day, week and timezone names case-insensitively.
- An HTTP/1.1 implementation MAY internally represent a parsed Expires date as earlier than the proper value, but MUST NOT internally represent a parsed Expires date as later than the proper value.
- All expiration-related calculations MUST be done in GMT. The local time zone MUST NOT influence the calculation or comparison of an age or expiration time.
- Caches SHOULD consider dates with time zones other than "GMT" invalid.
What is meant by "the most conservative possible conversion"?
Under this context, it doesn't seem to mean anything specifically aside from when faced with 2 outcomes, pick the most "conservative" date based on the context of the date.
Given 2 dates that was fuzzy parsed, in the context of a Last-modified header, the most conservative would be the "later" one. But in the context of a Expires header, the earlier of the 2 is more conservative. Anything requiring a significant amount of guessing should just return an error response.
