Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 30193200B40 for ; Fri, 1 Jul 2016 16:53:15 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2EA38160A61; Fri, 1 Jul 2016 14:53:15 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A6D18160A4D for ; Fri, 1 Jul 2016 16:53:13 +0200 (CEST) Received: (qmail 68801 invoked by uid 500); 1 Jul 2016 14:53:12 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 68791 invoked by uid 99); 1 Jul 2016 14:53:12 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jul 2016 14:53:12 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 904D7C7077 for ; Fri, 1 Jul 2016 14:53:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.029 X-Spam-Level: ** X-Spam-Status: No, score=2.029 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, KAM_INFOUSMEBIZ=0.75, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=enalean-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id H1HvZyzm7Aru for ; Fri, 1 Jul 2016 14:53:07 +0000 (UTC) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id EF22D5F478 for ; Fri, 1 Jul 2016 14:53:06 +0000 (UTC) Received: by mail-qk0-f182.google.com with SMTP id j2so151487069qkf.3 for ; Fri, 01 Jul 2016 07:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enalean-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zCr90WqZK8hNKdDAVx5VZ3kdF9ZfqxqGwisyWI/LPXc=; b=lmrugW5N/uCppNCZx+GBpS26Xhhdo0eJrPO2RIY0/cG+h9ML061htBYWSGuZPcgFgJ UWrCx/Q5R9CycTHmvxJ1jRXvNUIwKWrf2brkCpFel0CD8AOEzsqXm07HQXI8XEu8s/xt NRKpmEg7w5ku3TPDVUdtTrCHqKoJfFss1XMFsRy0JBAbcWVTqJX2trHG9wpTLb/VqQWC red/8YJWQ3pPb9lMoyGY9/AjZp7rwZM9tYlhuFtwVuO+Zc9YxJ9jnL6nn6vjWcZwJVAT eJfnT25EBY8bgCwr5sBLRT0DV3prXfajshL9YFkzRcjkyeApLYkqtYMJAzNw2cQhD2Tv tV8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zCr90WqZK8hNKdDAVx5VZ3kdF9ZfqxqGwisyWI/LPXc=; b=AeNwaUjloOrBXYGmKX5BALFJONQGbwhrijsYDYW88fwO73TeCSbHZ8YY248/Ua68n2 Q5i+EFoVP7YNCV11LDCaWM9sN5IdHvtOWZIuUBocQTcNjtOyDwIksNMWeAq9DUSv8j6O V2WHWN17YRNah1wJwu1uvIeWTPTNh0kNxqGCClurYTkY3WC8U7VneUerfFKwcKcE9glQ FafvX/GiKym/b0DsJdoVM82AvoxZvv9ypYu/yJPm2keTGApAfV5ForTxR0g7ePHH9I+T Hp7G0j24yjoAfChlqbLOVIn4ZRmmNCZcojDbIFF7H618CpfFFonE7wG/2fhA2nQ93ALo 5TYg== X-Gm-Message-State: ALyK8tKmg2pRBoB5ATGTIZ8DcJTcSA9zr4AgJ3mUcWLQWevlgDfwC+wmrj1nLPrNWMwezSatChpnINnEn7lrbTnp X-Received: by 10.129.88.139 with SMTP id m133mr9778638ywb.97.1467384785817; Fri, 01 Jul 2016 07:53:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.78 with HTTP; Fri, 1 Jul 2016 07:53:04 -0700 (PDT) In-Reply-To: References: From: "Vacelet, Manuel" Date: Fri, 1 Jul 2016 16:53:04 +0200 Message-ID: To: Luca Toscano Cc: users@httpd.apache.org Content-Type: multipart/alternative; boundary=001a1149313ce885e10536942445 Subject: Re: [users@httpd] Last-Modified header overridden archived-at: Fri, 01 Jul 2016 14:53:15 -0000 --001a1149313ce885e10536942445 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 1, 2016 at 4:14 PM, Luca Toscano wrote: > > > 2016-06-29 9:38 GMT+02:00 Luca Toscano : > >> >> >> 2016-06-28 18:32 GMT+02:00 Luca Toscano : >> >>> >>> >>> 2016-06-27 14:52 GMT+02:00 Vacelet, Manuel : >>> >>>> >>>> >>>> On Mon, Jun 27, 2016 at 2:17 PM, Luca Toscano >>>> wrote: >>>> >>>>> >>>>> >>>>> 2016-06-27 13:17 GMT+02:00 Vacelet, Manuel >>>> >: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Jun 25, 2016 at 11:00 AM, Luca Toscano < >>>>>> toscano.luca@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-06-24 17:26 GMT+02:00 Vacelet, Manuel < >>>>>>> manuel.vacelet@enalean.com>: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> Thanks a lot for the precise test! The same code snippet that I >>>>>>> modified is responsible for the behavior that you mentioned. Httpd modifies >>>>>>> the Last-Modified header with the request's modification time if the value >>>>>>> sent from FCGI appears to be in the future (since the HTTP RFC states "An >>>>>>> origin server with a clock MUST NOT send a Last-Modified date that is later >>>>>>> than the server's time of message origination (Date)."). >>>>>>> >>>>>>> I modified your PHP code snippet (http://apaste.info/EEz) trying to >>>>>>> compare a GMT date vs a "Europe/Paris" one, already formatted for RFC1123, >>>>>>> and PHP seems to agree with httpd in recognizing the "Europe/Paris" date as >>>>>>> more recent. Moreover, if you generate a GMT date and format it for RFC1123 >>>>>>> the header is not modified with the extra two seconds. >>>>>>> >>>>>>> So from what I can see httpd does the correct thing, I don't see a >>>>>>> bug like in the previous case. What do you think? I am far from a PHP >>>>>>> expert so I might have missed something important :) >>>>>>> >>>>>>> >>>>>> Mmm I don't think it' the right way to compare the dates here as you >>>>>> are really comparing the format strings here. >>>>>> I propose a new version of the snippet: http://apaste.info/Aox >>>>>> >>>>> >>>>>> Clearly, just changing the timezone doesn't impact the time >>>>>> comparison (and it's the expected behaviour). >>>>>> >>>>> >>>>> Correct, in general the best way should be the one that you proposed, >>>>> but in this case we are talking about RFC1123 specific date/times, so the >>>>> format string comparison should be relevant imho. A efficient RFC 822/1123 >>>>> parser would probably assume the GMT timezone and care only about what >>>>> comes before, this is why Europe/Paris is seen as more recent than GMT. A >>>>> super strict and correct parse would also check the GMT bit and return >>>>> error if missing, but it may be a bit overkill. >>>>> >>>>> >>>>>> To me there is a wrong attempt to comply with RFC in apache here. >>>>>> Either the parser is able to: >>>>>> 1. correctly read the header input >>>>>> 2. normalize to GMT >>>>>> 3. ensure the resulting date is not > to server time (+ probably log >>>>>> somthing to help developers to understand things) >>>>>> or there should be a warning and the header is dropped (like if it's >>>>>> not a date). >>>>>> >>>>>> Here I thing either step 1 ou 2 are no done properly in apache. >>>>>> >>>>>> >>>>> I am seeing things in a different way, namely only point 3 >>>>> should/could be implemented. AFAIU RFC1123 (and related) assume a GMT >>>>> date/time and since the HTTP RFC requires this format for the Last-Modified >>>>> header, I don't believe that httpd should be required to be able to convert >>>>> multiple formats/timezones to RFC1123. This seems to be backed up by the >>>>> comments of the function used by httpd to convert the Last-Modified header >>>>> value: >>>>> >>>> >>>> Ok but current behaviour is not correct either. >>>> >>> >>> From https://tools.ietf.org/html/rfc2616#section-14.29 >>> >>> An origin server MUST NOT send a Last-Modified date which is later >>> than the server's time of message origination. In such cases, where >>> the resource's last modification would indicate some time in the >>> future, the server MUST replace that date with the message >>> origination date. >>> >>> It also states that Last-Modified needs to be compliant with RFC >>> 882/1123. >>> >>> >>>> If I understood well assume that apache receives a RFC1123 value so it >>>> compares with current server time (and eventually sends the later). >>>> >>>> In my example, the date is not a valid RFC1123 value (because it sends >>>> +0200 or Europe/Paris). Here, the most sensible default would be to trash >>>> with value. >>>> It's as invalid as "foo" in my initial example so from my point of view >>>> the behaviour of apache should be the same: discard the header (thanks to >>>> your patch) and raise a warning. >>>> >>> >>> We could patch httpd/apr to be super strict but I am not sure if it is >>> worth it. In the meantime, I tried to improve logging, would you mind to >>> tell me what you think about http://apaste.info/JlZ ? >>> >> >> This one should be clearer: http://apaste.info/8pa >> >> I will also follow up with the dev@ mailing list to get other opinions >> about this bug report. >> >> >> > Committed logging in trunk and updated 2.4.x backport proposal: > http://svn.apache.org/r1750883 > > The logging message should look like: > > [Fri Jul 01 06:12:35.639343 2016] [proxy_fcgi:trace1] [pid 3542:tid > 140561097561856] util_script.c(688): [client ::1:52261] The Last-Modified > header value 'Fri, 01 Jul 2016 08:12:33 GMT' (parsed as RFC882/RFC1123 > datetime, that assumes the GMT timezone) has been replaced with: 'Fri, 01 > Jul 2016 06:12:35 GMT'. An origin server with a clock must not send a > Last-Modified date that is later than the server's time of message > origination. > > Thanks a lot for the bug report! > > Thanks for fixing it ! However it's RFC822 and not 882 (882 is for domain names: https://tools.ietf.org/html/rfc882) --001a1149313ce885e10536942445 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 1, 2016 at 4:14 PM, Luca Toscano <toscano.luca@gmail.= com> wrote:


20= 16-06-29 9:38 GMT+02:00 Luca Toscano <toscano.luca@gmail.com><= /span>:


2016-06-28 18:32 GMT+02:00 Luca T= oscano <toscano.luca@gmail.com>:
=


2016-06-27 14:52 GMT+02:00 Vacelet, Manuel = <manuel.= vacelet@enalean.com>:

On Mo= n, Jun 27, 2016 at 2:17 PM, Luca Toscano <toscano.luca@gmail.com&= gt; wrote:


2016-06-27 13:17 GMT+02= :00 Vacelet, Manuel <manuel.vacelet@enalean.com>:


On Sat, Jun 25, 2016 at 11:00 AM, Luca Tos= cano <toscano.luca@gmail.com> wrote:


2016-06-24 17:26 GMT+02:00 Vacelet, Manuel <manue= l.vacelet@enalean.com>:
=

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 <<= a href=3D"mailto:manuel.vacelet@enalean.com" target=3D"_blank">manuel.vacel= et@enalean.com>:

<= div class=3D"gmail_extra">
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&qu= ot; 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 incon= sistencies, so I went back and checked the correspondence. Quoting:

"Actually I wrote this snippet to highlight th= e 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 sen= t 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 !
=C2=A0
=

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) =C2=A0& 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 th= e record, I also have the same behaviour (headers rewritten when using php-= fpm + fastcgi) on alpine linux 3.4 that ships=C2=A0apache2-2.4.20.
So AFAICT, it doesn't seem distro specific.

= On the root of the problem, from my point of view:
- the differen= ce between mod_php vs. php-fpm + fcgi is understandable (even if not desire= d and not documented).
- the fact that fcgi handler parse & r= ewrite headers seems to lead to inconsistencies (I'll try to build a te= st case for that).
- however, even if the headers are wrong, I th= ink apache default (use EPOCH) is wrong as it leads to very inconsistent be= haviour (the resource will never expire). I would prefer either:=C2=A0
-- do not touch the header
-- raise a warning and discard t= he header

What do you think ?


From my tests the following snippet of code s= hould be responsible for the switch from 'foo' to unix epoch:
=

https://github.com/apache/httpd/blo= b/2.4.x/server/util_script.c#L663

The function that contains t= he code, ap_scan_script_header_err_core_ex, is wrapped by a lot of other fu= nctions eventually called by modules like mod-proxy-fcgi. A more verbose de= scription of the function in:

https://github.com/apache/= httpd/blob/2.4.x/include/util_script.h#L200

Not sure what would be the be= st thing to do, but probably we could follow up in a official apache bugzil= la task?=C2=A0https://bz.apache.org/bugzilla/ent= er_bug.cgi?product=3DApache%20httpd-2
<= br>

Wow, thanks for= the investigation !

Sorry f= or the delay! I submitted a patch for trunk with a possible fix, namely dro= pping (and logging at trace1 level) any non compliant date/time set in a La= st-Modified header returned by a FCGI/CGI script: http://svn.apache.org/r1748379


Cool :)
=C2=A0
The fi= x 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 gi= ve 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:
<= a href=3D"https://github.com/vaceletm/bug-httpd24/tree/time" target=3D"_bla= nk">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<= /div>
< Transfer-Encoding: chunked
< Content-Type: text= /html; charset=3DUTF-8
<=C2=A0
{ [data not shown]
=C2=A0 0 =C2=A0 =C2=A044 =C2=A0 =C2=A00 =C2=A0 =C2=A044 =C2=A0 =C2= =A00 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 21 =C2=A0 =C2=A0 =C2=A00 --:--:-- =C2=A0= 0:00:02 --:--:-- =C2=A0 =C2=A021* Connection #0 to host localhost left inta= ct

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

The value sent doesn't res= pect 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 GM= T"

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

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

Thanks a lot for the precise test! = The same code snippet that I modified is responsible for the behavior that = you mentioned. Httpd modifies the Last-Modified header with the request'= ;s modification time if the value sent from FCGI appears to be in the futur= e (since the HTTP RFC states "An origin server with a clock MUST NOT s= end a Last-Modified date that is later than the server's time of messag= e origination (Date).").=C2=A0

I modified you= r PHP code snippet (ht= tp://apaste.info/EEz) trying to compare a GMT date vs a "Europe/Pa= ris" one, already formatted for RFC1123, and PHP seems to agree with h= ttpd in recognizing the "Europe/Paris" date as more recent. Moreo= ver, if you generate a GMT date and format it for RFC1123 the header is not= modified with the extra two seconds.=C2=A0

So fro= m what I can see httpd does the correct thing, I don't see a bug like i= n the previous case. What do you think? I am far from a PHP expert so I mig= ht have missed something important :)

<= div>Mmm I don't think it' the right way to compare the dates here a= s you are really comparing the format strings here.
I propose a n= ew version of the snippet:=C2=A0http://apaste.info/Aox
=

Clearly, just changing the timezone doesn&= #39;t impact the time comparison (and it's the expected behaviour).

Correct, i= n general the best way should be the one that you proposed, but in this cas= e we are talking about RFC1123 specific date/times, so the format string co= mparison should be relevant imho. A efficient RFC 822/1123 parser would pro= bably assume the GMT timezone and care only about what comes before, this i= s why Europe/Paris is seen as more recent than GMT. A super strict and corr= ect parse would also check the GMT bit and return error if missing, but it = may be a bit overkill.=C2=A0
=C2=A0
=
To me there is a wrong attempt to comply with RFC in apache here.
Either the parser is able to:
1. correctly read the header inpu= t
2. normalize to GMT
3. ensure the resulting date is n= ot > to server time (+ probably log somthing to help developers to under= stand things)
or there should be a warning and the header is drop= ped (like if it's not a date).

Here I thing ei= ther step 1 ou 2 are no done properly in apache.

<= br>
I am seeing things in a different way, namely only poi= nt 3 should/could be implemented. AFAIU RFC1123 (and related) assume a GMT = date/time and since the HTTP RFC requires this format for the Last-Modified= header, I don't believe that httpd should be required to be able to co= nvert multiple formats/timezones to RFC1123. This seems to be backed up by = the comments of the function used by httpd to convert the Last-Modified hea= der value:=C2=A0

<= /div>
Ok but current behaviour is not correct either.
<= /div>


=C2=A0 =C2=A0An origin server MUST NOT send a Last-Modified date= which is later
=C2=A0 =C2=A0than the server's time of messag= e origination. In such cases, where
=C2=A0 =C2=A0the resource'= ;s last modification would indicate some time in the
=C2=A0 =C2= =A0future, the server MUST replace that date with the message
=C2= =A0 =C2=A0origination date.

It also states t= hat Last-Modified needs to be compliant with RFC 882/1123.
= =C2=A0
If I understood well assume that apache recei= ves a RFC1123 value so it compares with current server time (and eventually= sends the later).

In my example, the date is not = a valid RFC1123 value (because it sends +0200 or Europe/Paris). Here, the m= ost sensible default would be to trash with value.
It's as in= valid as "foo" in my initial example so from my point of view the= behaviour of apache should be the same: discard the header (thanks to your= patch) and raise a warning.

<= /div>
We could patch httpd/apr to be super strict but I am not s= ure if it is worth it. In the meantime, I tried to improve logging, would y= ou mind to tell me what you think about http://apaste.info/JlZ ?

This one should be clearer: http://apaste.info/8pa

I will also follow up with the dev@ mailing list to = get other opinions about this bug report.



Committed = logging in trunk =C2=A0and updated 2.4.x backport proposal:=C2=A0http://svn.apache.org/r1= 750883

The logging message should look like:

[Fri Jul 01 06:12:35.639343 2016] [proxy_fcgi:trace= 1] [pid 3542:tid 140561097561856] util_script.c(688): [client ::1:52261] Th= e Last-Modified header value 'Fri, 01 Jul 2016 08:12:33 GMT' (parse= d as RFC882/RFC1123 datetime, that assumes the GMT timezone) has been repla= ced with: 'Fri, 01 Jul 2016 06:12:35 GMT'. An origin server with a = clock must not send a Last-Modified date that is later than the server'= s time of message origination.

Thanks a lot for the bug report!


Thanks for fixing it !

However it's RFC822 and not 882 (882 is for domain names:=C2=A0https://tools.ietf.org/html/rfc882<= /a>)
=C2=A0
=
--001a1149313ce885e10536942445--