On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano <toscano.l...@gmail.com> wrote:
> > > 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel <manuel.vace...@enalean.com>: > >> >> >> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >> manuel.vace...@enalean.com> wrote: >> >>> 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). >>> >>> >> For the record, I also have the same behaviour (headers rewritten when >> using php-fpm + fastcgi) on alpine linux 3.4 that ships apache2-2.4.20. >> So AFAICT, it doesn't seem distro specific. >> >> On the root of the problem, from my point of view: >> - the difference between mod_php vs. php-fpm + fcgi is understandable >> (even if not desired and not documented). >> - the fact that fcgi handler parse & rewrite headers seems to lead to >> inconsistencies (I'll try to build a test case for that). >> - however, even if the headers are wrong, I think apache default (use >> EPOCH) is wrong as it leads to very inconsistent behaviour (the resource >> will never expire). I would prefer either: >> -- do not touch the header >> -- raise a warning and discard the header >> >> What do you think ? >> > > > From my tests the following snippet of code should be responsible for the > switch from 'foo' to unix epoch: > > *https://github.com/apache/httpd/blob/2.4.x/server/util_script.c#L663 > <https://github.com/apache/httpd/blob/2.4.x/server/util_script.c#L663>* > > The function that contains the code, ap_scan_script_header_err_core_ex, is > wrapped by a lot of other functions eventually called by modules like > mod-proxy-fcgi. A more verbose description of the function in: > > https://github.com/apache/httpd/blob/2.4.x/include/util_script.h#L200 > > Not sure what would be the best thing to do, but probably we could follow > up in a official apache bugzilla task? > https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2 > > Wow, thanks for the investigation ! I can open the bug on bugzilla but I'm not sure how to properly describe the problem.
