httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <toscano.l...@gmail.com>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Sat, 02 Jul 2016 00:05:45 GMT
2016-07-01 22:31 GMT+02:00 Yann Ylavic <ylavic.dev@gmail.com>:

> On Fri, Jul 1, 2016 at 10:17 PM, William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
> > On Fri, Jul 1, 2016 at 2:58 PM, Yann Ylavic <ylavic.dev@gmail.com>
> wrote:
> >>
> >> On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano <toscano.luca@gmail.com>
> >> wrote:
> >> >
> >> > "The Last-Modified header value '%s' (parsed assuming the GMT
> timezone)
> >> > has
> >> > been replaced with '%s' because considered in the future."
> >>
> >> Looks good to me (maybe "(GMT)" only between parentheses?).
> >>
> >> The original log message can still be switched to a comment, though ;)
> >
> >
> > I'm not fond of the 'assuming' thing, per RFC2616 it *is* defined as GMT.
> >
> > (parsed as GMT, as required)
> >
> > might be a way to phrase that? Other words that came to mind were
> > 'as defined', 'per spec', etc.
> >
> > Showing a value 'datetime (CEST)' (GMT) is unnecessarily confusing.
>

+1, really like the "as required", it is more readable and meaningful.


>
> Hmm, isn't "(CEST)" if there recognized by the parser (so to "correct"
> the compared epoch)?
> If so, this looks more like a bad "Last-Modified" than a future one
> (even if it's the case).
> (Sorry I didn't follow the discussion about this issue).
>
> Anyway, if we can find a timezone string in the header, "(GMT)" alone
> may be indeed confusing, but so is "parsed as GMT" IMHO.
>
> PS: if that has been discussed already, feel free to ignore me, I'll
> go looking at the thread :)
>

We have discussed it briefly in another email but didn't reach a
conclusion, so I am really happy to re-discuss it again. Maybe an example
would clarify what a user will see in the logs.

FCGI script returning the following header (Europe/Paris timezone):

Last-Modified: Sat, 02 Jul 2016 01:49:27 +0200

The current proposed logging (givent a proper LogLevel setting) would be:

[Fri Jul 01 23:49:29.173823 2016] [proxy_fcgi:trace4] [pid 3542:tid
140560966862592] util_script.c(564): [client ::1:52263]   Last-Modified:
Sat, 02 Jul 2016 01:49:27 +0200

[Fri Jul 01 23:49:29.173833 2016] [proxy_fcgi:trace1] [pid 3542:tid
140560966862592] util_script.c(688): [client ::1:52263] The Last-Modified
header value 'Sat, 02 Jul 2016 01:49:27 GMT' (parsed as RFC882/RFC1123
datetime, that assumes the GMT timezone) has been replaced with: 'Fri, 01
Jul 2016 23:49:29 GMT'. An origin server with a clock must not send a
Last-Modified date that is later than the server's time of message
origination.

[Fri Jul 01 23:49:29.173876 2016] [http:trace4] [pid 3542:tid
140560966862592] http_filters.c(835): [client ::1:52263]   Last-Modified:
Fri, 01 Jul 2016 23:49:29 GMT

Notice that the second log (the one that I added) shows both dates in GMT,
no mention of +0200. I didn't find a way to log the original value in the
code section that I changed (probably due to my inexperience), so I relied
on the fact that there is a complete dump of the FCGI headers before it.
This is why I added "parsed as RFC882/RFC1123 datetime, that assumes the
GMT timezone". I also got some feedback from users@ that the log flow was
clear so I proceeded with the commit.

As William wrote in the other thread,
https://tools.ietf.org/html/rfc2616#section-3.3.1 states that the GMT
timezone must be assumed by a datestr parser, and this is exactly what
apr_date_parse_http
seems to be doing.

"The Last-Modified header value '%s' (parsed as GMT date as required) has
been replaced with '%s' because considered in the future." could be a
possible solution. If this is still confusing, we could remove the "parsed
as .." bit.

Thanks!

Regards,

Luca

Mime
View raw message