On Wed, Jul 27, 2016 at 1:18 PM, Luca Toscano <toscano.l...@gmail.com> wrote:
> > 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! > Thanks for poking and moving this along :) I've stayed quite quiet to allow other voices to chime in... That still is the current RFC language, to be accomodating to non-HTTP providers and correct the data. Two concerns remain... 1. Why do you/reporter want HTTP applications to persist in writing code which breaks between different transport providers/cgi hosting environments? The language has been crystal clear for 2 decades. We do a huge disservice to the PHP author community to let them be idiots. Alternately, the PHP SAPI itself could rectify this. (We aren't talking about non-HTTP sources.) 2. Precisely which unexpected values have broken the test suite? I'm -1 to fix the suite until we understand the input data and the old-vs-new interpretation of that data. If there is date input that we cannot handle, the spec strongly encourages us to interpret it as now(), provided we have a clock (which all of our architectures do.)
