httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Thu, 28 Jul 2016 15:29:23 GMT
2016-07-28 16:05 GMT+02:00 William A Rowe Jr <>:

> On Thu, Jul 28, 2016 at 8:25 AM, Luca Toscano <>
> wrote:
>> 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).
> We all agree that behavior was nonsense, thanks for this aspect of the
> changes!
> That catch/fix can certainly be refreshed in the perl-framework already.
> 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.
> Yes, at least at loglevel trace, it is good to call out what httpd has
> manipulated.
>> 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.
> Are you sure? If their CGI/app is going to be thrown away soon, it is
> certainly convenient. If their CGI/app will have a life beyond it's current
> hosting environment, moved to another web server or cloud platform, we've
> just delayed the inevitable of their learning of their mistake.
> I'm perfectly happy to translate such values to GMT for non-HTTP inputs,
> per spec. If we are going to do so for HTTP inputs, loudly scolding the
> errant developer in the logs seems prudent, for their own longer-term
> benefit.
This is a good point, even if this behavior could be easily get spotted
with a bit of  testing before serving production traffic on the new
infrastructure/platform/etc.. :)

As said before, I am ok with both approaches: either the current trunk
patch or something less invasive like

Yann/Jacob, would it be ok for you to reduce the scope of the patch or is
it worth it to keep discussing alternative solutions? In the latter case
I'd really like to have more opinions from other readers of the list..



View raw message