httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Thu, 28 Jul 2016 14:05:20 GMT
On Thu, Jul 28, 2016 at 8:25 AM, Luca Toscano <toscano.luca@gmail.com>
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.

Mime
View raw message