2016-06-29 16:31 GMT+02:00 Luca Toscano <toscano.l...@gmail.com>: > > > 2016-06-29 14:06 GMT+02:00 William A Rowe Jr <wr...@rowe-clan.net>: > >> On Wed, Jun 29, 2016 at 3:12 AM, Luca Toscano <toscano.l...@gmail.com> >> wrote: >> >>> Hi Apache devs! >>> >>> I have been working on an email thread [1] in the users@ mailing list >>> in which it was asked some questions about how httpd (using mod-proxy-fcgi) >>> manages Last-Modified headers returned by FCGI/CGI scripts. Two strange >>> behaviors were brought up: >>> >>> 1) Last-Modified: foo returned by a simple PHP script forces httpd to >>> replace it with Thu, 01 Jan 1970 00:00:00 GMT. Patch proposed to backport: >>> http://svn.apache.org/r1748379 >>> >> >> Sensible, but we should be filling this in with now(), based on comments >> in 14.29? >> > > Very open to discuss this one, I have some doubts too. I chose to drop the > header since I applied 14.29 only to dates (i.e. not triggering any > APR_DATE_BAD after parsing) and not to completely wrong values like "foo". > My aim was to drop any non parsable date (logging the action) and to > correct the rest if considered in the future from httpd's point of view. > > >> >> >>> 2) Last-Modified header value with a date not in GMT are replaced with >>> (now() + time taken to serve the request) without any trace in the logs. >>> This seems to be due to httpd recognizing the date as "in the future" and >>> replacing it with its response origination time (following >>> https://tools.ietf.org/html/rfc2616#section-14.29). >>> >> >> https://tools.ietf.org/html/rfc2616#section-3.3.1 declares these are >> meaningless, and we follow the appropriate recommendations. >> > > +1, completely missed this part: "This is indicated in the first two > formats by the inclusion of "GMT" as the three-letter abbreviation for time > zone, and MUST be assumed when reading the asctime format." > > >> >> >>> To demonstrate 2), Manuel in users@ suggested a simple PHP script >>> returning the current datetime in the Europe/Paris timezone (GMT +2). I >>> tried to check the code and I came up with two possible solutions: >>> >>> 1) mod-proxy-fcgi eventually triggers a call >>> to ap_scan_script_header_err_core_ex in util_script.c that >>> uses apr_date_parse_http to transform a datestring into a unix timestamp. >>> This one seems not to check the timezone, assuming GMT all the times. It >>> might be an option to add a check in the code to return APR_DATE_BAD in >>> case the datetime is not GMT, and then r1748379 will take care of the rest. >>> This could potentially break existing code that relies on this behavior to >>> work correctly. >>> >> >> -0 on recognizing non-GMT, per section 3.3.1 of spec. >> > > Yes completely agree. > > >> >> >>> 2) Simply log what httpd does, for example with http://apaste.info/8pa >>> or http://apaste.info/JlZ (wording might need to be changed). >>> >> >> +1 in all cases to adding trace messages for sysadmins debugging bad cgi. >> >> Added logging in http://svn.apache.org/r1750747 and http://svn.apache.org/r1750749 (last one is to fix indentation issues, my bad).
It would be good to get other comments for http://svn.apache.org/r1748379, to follow up on what William suggested in his previous email. Thanks! Regards, Luca
