Hi Luca,
On Mon, May 30, 2016 at 1:45 PM, Luca Toscano <toscano.l...@gmail.com>
wrote:
> Hi Manuel!
>
> 2016-05-27 14:28 GMT+02:00 Vacelet, Manuel <manuel.vace...@enalean.com>:
>
>> Hi all,
>>
>> I got a weird behavior with apache 2.4.12 (from RHEL scl for that matter).
>>
>> I have a php application (behind fcgi/fpm) that sets Last-Modified header
>> like:
>> <?php header('Last-Modified: never');
>>
>> but when I curl the page, the header sent is:
>> < Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
>>
>> When the date is correct in my php app, the returned value is OK but as
>> soon as it's not RFC valid, it's modified.
>>
>
> I am probably missing some bits of information, but what is the use case
> to send a HTTP response with a well known header not following the RFC? I
> didn't check the code but I would expect httpd to enforce the RFC when
> needed rather than simply returning what the backend issues.
>
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 I suspect that something is modifying the headers but I fail to
understand what/why.
Moreover, the result is not consistent across the server vendors/versions,
headers are not modified with:
- stock apache 2.2 on centos6
- SCL nginx 1.8 on centos6
- stock apache 2.4 on alpine
- stock apache 2.4 on centos7
Actually, the only place where I've see the date modified is on apache
2.4.12 from RedHat SCLs.
As there are no obvious patch in the package that change this behaviour I
wanted to know if it might come from a configuration or build option.
Manuel
