The Last-Modified header coming from a backend FCGI/CGI script is inspected by util_script.c to enforce RFC2616 (https://tools.ietf.org/html/rfc2616#section-14.29). The Last-Modified header also needs to be compliant with RFC882/1123 as stated in https://tools.ietf.org/html/rfc2616#section-3.3.1, and one important assumption that httpd makes (correctly, as the RFC suggests) is to assume the GMT timezone. If the datestr returned by the FCGI/CGI script is set with a different timezone, then the value might be considered "in the future" and replaced with GMT now() as calculated by httpd. Adding a trace log might help sysadmins while debugging these kind of issues. This is a follow up of r1748379.
Drop an invalid Last-Modified header value returned by a FCGI/CGI script instead tranforming it to Unix Epoch.
This bug was mentioned in the users@ mailing list and outlined in the following centos bug: https://bugs.centos.org/view.php?id=10940 To reproduce the issue it is sufficient to connect mod-fastcgi to a PHP script that returns a HTTP response with the header "Last-Modified: foo". The header will be modified by script_util.c to "Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT". Dropping an invalid header in this case seems to be the most consistent and correct option in my opinion, plus it shouldn't break existing configurations. Returning Unix Epoch might be dangerous and should be avoided, but please let me know your opinions. Moreover this is my first commit outside the documentation court, I hope to have got the procedure right. This fix has been tested also with the 2.4.x branch.