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 Fri, 24 Jun 2016 15:26:07 GMT
On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano <toscano.luca@gmail.com>
wrote:

>
>
> 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel <manuel.vacelet@enalean.com>:
>
>> 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 !
>>
>
> Sorry for the delay! I submitted a patch for trunk with a possible fix,
> namely dropping (and logging at trace1 level) any non compliant date/time
> set in a Last-Modified header returned by a FCGI/CGI script:
> http://svn.apache.org/r1748379
>
>
Cool :)


> The fix is also in the list of proposal for backport to the 2.4.x branch,
> we'll see what other people think about this solution.
>
> We should also do a follow up for the other main issue, namely the fact
> that you see a different/delayed Last-Modified header sometimes among your
> FCGI/httpd responses. Can you give me an example of Last-Modified header
> value before/after the "delay" and a way to repro it?
>

I wrote a test case in the "time" branch:
https://github.com/vaceletm/bug-httpd24/tree/time

In my own tests, I get:
--------------------->8---------------------
< Date: Fri, 24 Jun 2016 15:21:46 GMT
< Server: Apache/2.4.18 (Red Hat)
< X-Powered-By: PHP/5.6.5
< Last-Modified: Fri, 24 Jun 2016 15:21:48 GMT
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
{ [data not shown]
  0    44    0    44    0     0     21      0 --:--:--  0:00:02 --:--:--
 21* Connection #0 to host localhost left intact

* Closing connection #0
sent value: Fri, 24 Jun 2016 17:21:46 +0200
--------------------->8---------------------

The value sent doesn't respect RFC1123 (+0200 instead of GMT as time zone)
but the result is weird as you can see:
- I sent "Fri, 24 Jun 2016 17:21:46 +0200"
- but apache decided to send "Fri, 24 Jun 2016 15:21:48 GMT"

Notice the 2 seconds ?
I put a "sleep(2)" in my php script...

I don't know if your fix also take this into account

Mime
View raw message