2016-07-25 14:41 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>: > 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. >
Anybody else that would like to add his opinion? The more the better, I'd really like to reach a common agreement! Luca
