On Fri, Jul 22, 2016 at 8:42 PM, Jacob Champion <champio...@gmail.com> wrote: > On 07/22/2016 10:49 AM, William A Rowe Jr wrote: >> >> I'm -1 for interpretating invalid values. > > > By "invalid" do you mean any string that doesn't comply with 723x's > Last-Modified definition? Even if the only non-compliance is the use of a > non-GMT timezone? > > I'm not personally a fan of all the strange date formats handled by the > parse_rfc() function, but it seems like timezone translation is something we > can easily/usefully/safely do.
+1 Bill, you previously quoted rfc7231#section-7.1.1.1's: "Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format. " I read this as being able to parse well known valid dates (GMT or not, which is what parse_rfc() is for), provided we output rfc7231 valid/future/GMT ones only. Why couldn't we do so? > >> The new behavior was wrong, it should be set to now() for all >> invalidinput IMHO > > > In my opinion, turning a completely invalid string (e.g. "Last-Modified: > blahblahblah") into a current Last-Modified stamp *is* interpretation. We'd > be attaching a Last-Modified value to a resource that doesn't really deserve > one. Again +1, either we are strict and error out on bad dates, or we are lenient in what we get (to some extent) and do right thing (GMT) in what we set. Regards, Yann.
