httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Wed, 27 Jul 2016 18:26:25 GMT
On Wed, Jul 27, 2016 at 1:18 PM, Luca Toscano <>

> 2016-07-25 14:41 GMT+02:00 Yann Ylavic <>:
>> On Fri, Jul 22, 2016 at 8:42 PM, Jacob Champion <>
>> 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-'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
interpretation of that data. If there is date input that we cannot handle,
spec strongly encourages us to interpret it as now(), provided we have a
clock (which all of our architectures do.)

View raw message