httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <>
Subject Re: [users@httpd] Last-Modified header overridden
Date Tue, 07 Jun 2016 21:02:59 GMT
2016-06-07 10:55 GMT+02:00 Vacelet, Manuel <>:

> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel <
>> wrote:
>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel <
>>> wrote:
>>> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano <>
>>> 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:


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:

Not sure what would be the best thing to do, but probably we could follow
up in a official apache bugzilla task?

Any thoughts by other readers of the email list?


View raw message