2016-07-01 22:31 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>: > On Fri, Jul 1, 2016 at 10:17 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Fri, Jul 1, 2016 at 2:58 PM, Yann Ylavic <ylavic....@gmail.com> > wrote: > >> > >> On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano <toscano.l...@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
