2016-07-27 20:26 GMT+02:00 William A Rowe Jr <wr...@rowe-clan.net>: > 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.) >
The first version of the change tried to solve an actual bug imho, namely returning Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT when the FCGI backend returned something like Last-Modified: bad-value-here (more precisely, trying to translate APR_DATE_BAD into a datetime value). I also agree 100% with Jacob and Yann that adding Last-Modified: now() for this use case is not great, we'd add the wrong semantic to an incorrect state. Then we tried to focus on how httpd interprets non GMT datetimes, discovering that in some cases httpd overrides were not trivial to understand. For example from the original report: PHP script execution time: 2 seconds FCGI/PHP header: Last-Modified: Fri, 24 Jun 2016 17:21:46 +0200 HTTPD header: Last-Modified: Fri, 24 Jun 2016 15:21:48 GMT (that was basically now() at the time) Httpd replaced the backend Last-Modified value (considered invalid) with now(), adding 2 extra seconds to the original value as consequence (httpd + PHP processing time) without any trace of the action in the logs. I agree that in the perfect world people should read RFCs and write their application accordingly, but most of the times this does not happen and a bit of flexibility in a tool like httpd would make a lot of people happier :) As Yann mentioned it would be great to interpret the RFCs in a way that could benefit users giving added value to httpd, but if this is too much we can also agree to keep the existing behavior adding only logs for the users. The first option seems to be better from the users point of view, that's all. > 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.) > Maybe I am missing something but afaik nothing has broken the test suite. Jacob is trying to add more test cases and his patch adds a completely new test for this specific change to avoid any regressions in the future. Regards, Luca
