When Date doesn't parse

[mnot]

Date specifies what to do when it isn't present (use the received time), but not what to do when it doesn't parse.

The intuitive thing to do is align, and say that the received time should be used in this situation as well -- but probably not require implementations to replace it if forwarded.

I might write some tests...

[royfielding]

Assuming you are talking about Age, yes, go with the intuitive sense. I think some people might claim an invalid value should make it non-cacheable, but given that Age is added by an intermediary (not by the responsible origin), I think it should be ignored when invalid.

[royfielding]

Okay, I am still waiting on those new glasses. Too much Age.

It's fine with me if we interpret an invalid Date as the received time, but that assumes we know the received time when we parse the Date. I think as long as the scope is specific to Caching, we should specify that a cache always record the time received (regardless of Date) and use the received time if the Date field value is invalid.

[mnot]

Date is used in a number of places in caching, so that modification will be pretty invasive.

Why do you think it needs to be restrained to just caching?

I suppose it could be specified in semantics as something like 'If the Date field value does not parse, it MAY be replaced with the time the message was received. Caches SHOULD consider the message receipt time as the Date value when it cannot be parsed.'

[martinthomson]

The "it" in that last sentence has an unclear subject (is it the date, the arrival time, or the cache?), and "consider" -> "use".

[royfielding]

The only reason I said it is okay for caching is because we already depend on the cache having a clock and storing time received. It seems reasonable, regardless of role, if the recipient has a clock. But I wasn't suggesting a new requirement.