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. > > Thank you for the feedback! Regards, Luca
