dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel <manuel.vace...@enalean.com > wrote:
> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano <toscano.l...@gmail.com> > wrote: > >> >> I was able to repro building httpd from 2.4.x branch and following your >> configuration files on github. I am almost sure that somewhere httpd sets >> the Last-Modified header translating "foo" to the first Jan 1970 date. I >> realized though that I didn't recall the real issue, since passing value >> not following the RFC can lead to inconsistencies, so I went back and >> checked the correspondence. Quoting: >> >> "Actually I wrote this snippet to highlight the behaviour (the original >> code sent the date in iso8601 instead of rfc1123) because it was more >> obvious. >> During my tests (this is extracted from an automated test suite), even >> after having converted dates to rfc1123, I continued to get some sparse >> errors. What I got is that the value I sent was sometimes slightly modified >> (a second or 2) depending on the machine load." >> >> So my understanding is that you would like to know why a Last-Modified >> header with a legitimate date/time set by a PHP app gets "delayed" by a >> couple of seconds from httpd, right? >> > > Yes for sure, this is the primary issue. > However, the (undocumented) difference of behavior from one version to > another (2.2 -> 2.4 and more surprisingly from between two 2.4 versions) is > also in question here. > Even more strange, 2.4 built for other distrib doesn't highlight the > behaviour ! > > I made another series of test and it seems to be linked to fastcgi. I took the stock apache (2.4.6 plus tons of patches) & php-fpm (5.4.16 + tons of patches) from RHEL7 and I get the exact same behaviour (headers rewritten to EPOCH) However, if I server the very same php script from mod_php (instead of fcgi) it "works" (the headers are not modified). Manuel
