httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vacelet, Manuel" <manuel.vace...@enalean.com>
Subject Re: [users@httpd] Last-Modified header overridden
Date Wed, 08 Jun 2016 14:14:32 GMT
On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano <toscano.luca@gmail.com>
wrote:

>
>
> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel <manuel.vacelet@enalean.com>:
>
>>
>>
>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel <
>> manuel.vacelet@enalean.com> wrote:
>>
>>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel <
>>> manuel.vacelet@enalean.com> wrote:
>>>
>>>> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano <toscano.luca@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.

Mime
View raw message