2016-07-23 1:18 GMT+02:00 Jacob Champion <champio...@gmail.com>: > On 07/22/2016 01:38 PM, William A Rowe Jr wrote: > >> RFC 7231 § 7.1.1 >> RFC 7232 § 2.2 >> > > Okay, at least we're looking at the same sections then. But I'm not > finding support for your statement that we must replace completely > unintelligible Last-Modified values with current timestamps. The closest I > found was this: > > An origin server with a clock MUST NOT send a Last-Modified date that >> is later than the server's time of message origination (Date). If >> the last modification time is derived from implementation-specific >> metadata that evaluates to some time in the future, according to the >> origin server's clock, then the origin server MUST replace that value >> with the message origination date. >> > > which does not apply to completely invalid data, just future timestamp > metadata. A "Last-Modified: complete-junk" header coming from a CGI > implementation is not a "future" timestamp; it's complete junk, and IMO we > should not promote it to *any* authoritative value. We should treat it as > if no Last-Modified header was sent at all. > > Also, since we're talking about CGI here (which IIUC is an implementation > detail as far as HTTP is concerned), 7.1.1.1 has this to say: > > Note: HTTP requirements for the date/time stamp format apply only >> to their usage within the protocol stream. Implementations are >> not required to use these formats for user presentation, request >> logging, etc. >> > > CGI communication is not part of the protocol stream. As long as we don't > run afoul of any CGI-related RFCs that lock us into a specific > interpretation of junk header data, 723x appears (to me) to have no > prohibition on fixing up or removing bad HTTP-dates coming from an internal > CGI backend. It's up to us to determine what is most correct/useful > behavior. (The situation might be different if we were talking about a > cache or a proxy, but we're not.) > > Am I missing any relevant sections here? > > (Unfortunately I won't be able to continue my part of the conversation > next week since I'll be out of the office; hopefully others will put in > their two cents.) > > First of all thanks all for the good discussion, I am going to add my two cents. So I can see two relevant and separate changes:
1) Any invalid value like "Last-Modified: foo" (that generates a APR_DATE_BAD from APR) should be considered bogus and dropped, leaving a meaningful trace for the admin. This would be great in my opinion since httpd should be a "safe net" for honest mistakes made by backend developers that might accidentally introduce bogus headers like this one. I am not seeing any good use case that would legitimate turning a value like "foo" into a valid GMT datetime. 2) Interpreting header values not strictly allowed turning them into a valid GMT datetime value would be a good feature for httpd and something that our users will like (as stated for example by the person that brought up this issue on users@), but we need of course to consider the RFCs first. As Jacob pointed out I don't see any piece of the 723x RFCs stating clearly that the new proposed behavior is wrong, but I also value a lot William's experience in dealing with RFCs so it might be good to re-think the patch to something less intrusive like http://apaste.info/LiB. This patch would be a compromise between my initial proposal and Yann's. Example: PHP script returning Last-Modified: Sat, 23 Jul 2016 10:00:27 +0200 GMT now: Sat, 23 Jul 2016 08:00:27 GMT Header returned by httpd: Last-Modified: Sat, 23 Jul 2016 08:00:27 GMT Logs: util_script.c(564): [client ::1:44380] Last-Modified: Sat, 23 Jul 2016 10:00:27 +0200 util_script.c(683): [client ::1:44380] The Last-Modified header value 'Sat, 23 Jul 2016 10:00:27 +0200' (in the future considering the GMT timezone) has been replaced with 'Sat, 23 Jul 2016 08:00:27 GMT' http_filters.c(835): [client ::1:44380] Last-Modified: Sat, 23 Jul 2016 08:00:27 GMT The wording could be different of course, I am a non native english speaker so please let me know if there is anything better than these messages. Caveat: any httpd processing time would be added to the final Last-Modified value, something that confused a lot the person that brought up this issue on users@ (original repro case from users@: https://github.com/vaceletm/bug-httpd24/blob/time/headers.php). I am happy with any solution that we choose, as long as we reach a final and shared agreement without getting stuck for too long (with the risk of adding dust and dropping this change completely). Regards, Luca
