Re: [users@httpd] Last-Modified header overridden
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.l...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-06-24 17:26 GMT+02:00 Vacelet, Manuel < >>>>>>> manuel.vace...@enalean.com>: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano < >>>>>>>> toscano.l...@gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel < >>>>>>>>> manuel.vace...@enalean.com>: >>>>>>>>> >>>>>>>>>> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano < >>>>>>>>>> toscano.l...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel < >>>>>>>>>>> manuel.vace...@enalean.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >>>>>>>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < >>>>>>>>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano < >>>>>>>>>>>>>> toscano.l...@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 >>>>>>>>>>>>>
Re: [users@httpd] Last-Modified header overridden
On Tue, Jun 28, 2016 at 6:32 PM, Luca Toscano wrote: > > > 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 >>>> wrote: >>>> >>>>> >>>>> >>>>> 2016-06-24 17:26 GMT+02:00 Vacelet, Manuel >>>> >: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel < >>>>>>> manuel.vace...@enalean.com>: >>>>>>> >>>>>>>> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano < >>>>>>>> toscano.l...@gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel < >>>>>>>>> manuel.vace...@enalean.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >>>>>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>>>>> >>>>>>>>>>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < >>>>>>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano < >>>>>>>>>>>> toscano.l...@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 >>&
Re: [users@httpd] Last-Modified header overridden
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 >> wrote: >> >>> >>> >>> 2016-06-24 17:26 GMT+02:00 Vacelet, Manuel : >>> >>>> >>>> >>>> On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano >>>> wrote: >>>> >>>>> >>>>> >>>>> 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel >>>> >: >>>>> >>>>>> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel < >>>>>>> manuel.vace...@enalean.com>: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >>>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>>> >>>>>>>>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < >>>>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>>>> >>>>>>>>>> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano < >>>>>>>>>> toscano.l...@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 >>>>>&
Re: [users@httpd] Last-Modified header overridden
On Sat, Jun 25, 2016 at 11:00 AM, Luca Toscano wrote: > > > 2016-06-24 17:26 GMT+02:00 Vacelet, Manuel : > >> >> >> On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano >> wrote: >> >>> >>> >>> 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel : >>> >>>> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano >>>> wrote: >>>> >>>>> >>>>> >>>>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel >>>> >: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >>>>>> manuel.vace...@enalean.com> wrote: >>>>>> >>>>>>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < >>>>>>> manuel.vace...@enalean.com> wrote: >>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 4:09 PM, Luca Toscano < >>>>>>>> toscano.l...@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
Re: [users@httpd] Last-Modified header overridden
On Sun, Jun 19, 2016 at 3:17 PM, Luca Toscano wrote: > > > 2016-06-08 16:14 GMT+02:00 Vacelet, Manuel : > >> On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano >> wrote: >> >>> >>> >>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel : >>> >>>> >>>> >>>> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >>>> manuel.vace...@enalean.com> wrote: >>>> >>>>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < >>>>> manuel.vace...@enalean.com> 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: >>> >>> *https://github.com/apache/httpd/blob/2.4.x/server/util_script.c#L663 >>> <h
Re: [users@httpd] Last-Modified header overridden
On Tue, Jun 7, 2016 at 11:02 PM, Luca Toscano wrote: > > > 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel : > >> >> >> On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel < >> manuel.vace...@enalean.com> wrote: >> >>> dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < >>> manuel.vace...@enalean.com> 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: > > *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.
Re: [users@httpd] Last-Modified header overridden
On Mon, Jun 6, 2016 at 5:32 PM, Vacelet, Manuel wrote: > dOn Mon, Jun 6, 2016 at 5:00 PM, Vacelet, Manuel < > manuel.vace...@enalean.com> 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 ?
Re: [users@httpd] Last-Modified header overridden
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). Manuel
Re: [users@httpd] Last-Modified header overridden
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 ! > > The next step that I want to try is to add more logging in the C files > where the Last-Modified header is set via apr_table_setn to narrow down the > code responsible for this behavior (please everybody let me know if you > have a better/smarter/etc idea :). > > I built apache on my own with the same arguments from the redhat package (and without any patches) and I got the error. So, as far as I understand, this is the default behaviour of apache. The question is now: why I don't get the bug on ubuntu or alpine ? Manuel
Re: [users@httpd] Last-Modified header overridden
On Mon, Jun 6, 2016 at 1:36 PM, Vacelet, Manuel wrote: > Hi Luca > > On Sat, Jun 4, 2016 at 4:54 PM, Luca Toscano > wrote: > >> >> Can you post the list of modules that you have loaded plus your full >> httpd config (maybe you can upload them to the bug report)? Another think >> to try would be to use gdb and http -X to trace one process, but it might >> be overkill. You could also try to add trace-log specific prints in the >> httpd .c files where Last-Modified is changed to see if anything comes up, >> but again it might be very time consuming. >> >> I tried to repro on 2.4.20 but I wasn't able, so I took a look to >> https://www.apache.org/dist/httpd/CHANGES_2.4 to see if it was something >> corrected with 2.4.13 but I didn't see anything obvious. You also mentioned >> that there seem to be no distro specific patches applied to the httpd >> package, so the issue might be really difficult to track. >> >> Will try to check you docker image during the next days, maybe we can >> come up with something. In the meantime, is there any possibility to switch >> to a different httpd version (that works) to unblock you? >> >> Luca >> >> > I hoped there might be some "obvious" configuration stuff that might > affected the behaviour but it seems to be a very specific bug. > I don't know how to use gdb in this situation, if you have any hint, I > would be happy to give it a try. > > I will start by rebuilding the package without the patches to see where > the things starts to get bad. > > Hmm :/ I rebuilt the package with all the patches (but one to adapt to RHEL/Fedora layout) removed and it still doesn't work.
Re: [users@httpd] Last-Modified header overridden
Hi Luca On Sat, Jun 4, 2016 at 4:54 PM, Luca Toscano wrote: > > Can you post the list of modules that you have loaded plus your full httpd > config (maybe you can upload them to the bug report)? Another think to try > would be to use gdb and http -X to trace one process, but it might be > overkill. You could also try to add trace-log specific prints in the httpd > .c files where Last-Modified is changed to see if anything comes up, but > again it might be very time consuming. > > I tried to repro on 2.4.20 but I wasn't able, so I took a look to > https://www.apache.org/dist/httpd/CHANGES_2.4 to see if it was something > corrected with 2.4.13 but I didn't see anything obvious. You also mentioned > that there seem to be no distro specific patches applied to the httpd > package, so the issue might be really difficult to track. > > Will try to check you docker image during the next days, maybe we can come > up with something. In the meantime, is there any possibility to switch to a > different httpd version (that works) to unblock you? > > Luca > > I hoped there might be some "obvious" configuration stuff that might affected the behaviour but it seems to be a very specific bug. I don't know how to use gdb in this situation, if you have any hint, I would be happy to give it a try. I will start by rebuilding the package without the patches to see where the things starts to get bad. For what is worth, I tried with an updated version of the package (based on 2.4.18) and I got the same result. Here is the new trace: [Mon Jun 06 11:32:41.663635 2016] [suexec:notice] [pid 55] AH01232: suEXEC mechanism enabled (wrapper: /opt/rh/httpd24/root/usr/sbin/suexec) [Mon Jun 06 11:32:41.671425 2016] [auth_digest:notice] [pid 56] AH01757: generating secret for digest authentication ... [Mon Jun 06 11:32:41.671568 2016] [http2:warn] [pid 56] AH02951: mod_ssl does not seem to be enabled [Mon Jun 06 11:32:41.672107 2016] [lbmethod_heartbeat:notice] [pid 56] AH02282: No slotmem from mod_heartmonitor [Mon Jun 06 11:32:41.674127 2016] [mpm_prefork:notice] [pid 56] AH00163: Apache/2.4.18 (Red Hat) configured -- resuming normal operations [Mon Jun 06 11:32:41.674150 2016] [core:notice] [pid 56] AH00094: Command line: '/opt/rh/httpd24/root/usr/sbin/httpd' [Mon Jun 06 11:32:41.676422 2016] [http2:trace1] [pid 58] h2_h2.c(596): [client ::1:59372] h2_h2, process_conn [Mon Jun 06 11:32:41.676473 2016] [core:trace5] [pid 58] protocol.c(616): [client ::1:59372] Request received from client: GET /headers.php HTTP/1.1 [Mon Jun 06 11:32:41.676497 2016] [http:trace4] [pid 58] http_request.c(394): [client ::1:59372] Headers received from client: [Mon Jun 06 11:32:41.676501 2016] [http:trace4] [pid 58] http_request.c(398): [client ::1:59372] User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 [Mon Jun 06 11:32:41.676503 2016] [http:trace4] [pid 58] http_request.c(398): [client ::1:59372] Host: localhost [Mon Jun 06 11:32:41.676505 2016] [http:trace4] [pid 58] http_request.c(398): [client ::1:59372] Accept: */* [Mon Jun 06 11:32:41.676634 2016] [authz_core:debug] [pid 58] mod_authz_core.c(809): [client ::1:59372] AH01626: authorization result of Require all granted: granted [Mon Jun 06 11:32:41.676644 2016] [authz_core:debug] [pid 58] mod_authz_core.c(809): [client ::1:59372] AH01626: authorization result of : granted [Mon Jun 06 11:32:41.676646 2016] [core:trace3] [pid 58] request.c(293): [client ::1:59372] request authorized without authentication by access_checker_ex hook: /headers.php [Mon Jun 06 11:32:41.676718 2016] [proxy:trace2] [pid 58] proxy_util.c(1989): [client ::1:59372] *: using default reverse proxy worker for fcgi:// 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php (no keepalive) [Mon Jun 06 11:32:41.676724 2016] [proxy:debug] [pid 58] mod_proxy.c(1160): [client ::1:59372] AH01143: Running scheme fcgi handler (attempt 0) [Mon Jun 06 11:32:41.676728 2016] [proxy_ajp:debug] [pid 58] mod_proxy_ajp.c(738): [client ::1:59372] AH00894: declining URL fcgi:// 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php [Mon Jun 06 11:32:41.676731 2016] [proxy_fcgi:debug] [pid 58] mod_proxy_fcgi.c(879): [client ::1:59372] AH01076: url: fcgi:// 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php proxyname: (null) proxyport: 0 [Mon Jun 06 11:32:41.676734 2016] [proxy_fcgi:debug] [pid 58] mod_proxy_fcgi.c(886): [client ::1:59372] AH01078: serving URL fcgi:// 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php [Mon Jun 06 11:32:41.676737 2016] [proxy:debug] [pid 58] proxy_util.c(2160): AH00942: FCGI: has acquired connection for (*) [Mon Jun 06 11:32:41.676743 2016] [proxy:debug] [pid 58] proxy_util.c(2213): [client ::1:59372] AH00944: connecting fcgi:// 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php to 127.0.0.1:9000 [Mon Jun 06 11:32:41.676782 2016] [proxy:debug] [pid 58] proxy_util.c(2422): [client ::1:59372] AH00947: connec
Re: [users@httpd] Last-Modified header overridden
Hi, Any insights from the logs, where can I look now ? On Tue, May 31, 2016 at 5:12 PM, Vacelet, Manuel wrote: > > On Tue, May 31, 2016 at 3:00 PM, Luca Toscano > wrote: > >> >> Another info that it would be great to know: have you tried to set logs >> to debug level to see if httpd can suggest you what it is doing? >> >> https://httpd.apache.org/docs/2.4/mod/core.html#loglevel >> >> > Good idea, with trace8 I get interesting results (I highlighted the > interesting parts): > > Starting php-fpm: [ OK ] > Starting httpd: [Tue May 31 15:08:38.074202 2016] [core:trace3] [pid 46] > core.c(3060): Setting LogLevel for all modules to trace8 > AH00558: httpd: Could not reliably determine the server's fully qualified > domain name, using 172.17.42.7. Set the 'ServerName' directive globally to > suppress this message >[ OK ] > * About to connect() to localhost port 80 (#0) > * Trying ::1... connected > * Connected to localhost (::1) port 80 (#0) > > GET /headers.php HTTP/1.1 > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: localhost > > Accept: */* > > > < HTTP/1.1 200 OK > < Date: Tue, 31 May 2016 15:08:38 GMT > < Server: Apache/2.4.12 (Red Hat) > < X-Powered-By: PHP/5.6.5 > < Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > < Content-Length: 0 > < Content-Type: text/html; charset=UTF-8 > < > * Connection #0 to host localhost left intact > * Closing connection #0 > [Tue May 31 15:08:38.075284 2016] [suexec:notice] [pid 46] AH01232: suEXEC > mechanism enabled (wrapper: /opt/rh/httpd24/root/usr/sbin/suexec) > [Tue May 31 15:08:38.082708 2016] [auth_digest:notice] [pid 47] AH01757: > generating secret for digest authentication ... > [Tue May 31 15:08:38.083440 2016] [lbmethod_heartbeat:notice] [pid 47] > AH02282: No slotmem from mod_heartmonitor > [Tue May 31 15:08:38.084944 2016] [mpm_prefork:notice] [pid 47] AH00163: > Apache/2.4.12 (Red Hat) configured -- resuming normal operations > [Tue May 31 15:08:38.084972 2016] [core:notice] [pid 47] AH00094: Command > line: '/opt/rh/httpd24/root/usr/sbin/httpd' > [Tue May 31 15:08:38.088052 2016] [core:trace5] [pid 49] protocol.c(618): > [client ::1:54638] Request received from client: GET /headers.php HTTP/1.1 > [Tue May 31 15:08:38.088099 2016] [http:trace4] [pid 49] > http_request.c(301): [client ::1:54638] Headers received from client: > [Tue May 31 15:08:38.088105 2016] [http:trace4] [pid 49] > http_request.c(305): [client ::1:54638] User-Agent: curl/7.19.7 > (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 > libidn/1.18 libssh2/1.4.2 > [Tue May 31 15:08:38.088109 2016] [http:trace4] [pid 49] > http_request.c(305): [client ::1:54638] Host: localhost > [Tue May 31 15:08:38.088112 2016] [http:trace4] [pid 49] > http_request.c(305): [client ::1:54638] Accept: */* > [Tue May 31 15:08:38.088292 2016] [authz_core:debug] [pid 49] > mod_authz_core.c(809): [client ::1:54638] AH01626: authorization result of > Require all granted: granted > [Tue May 31 15:08:38.088300 2016] [authz_core:debug] [pid 49] > mod_authz_core.c(809): [client ::1:54638] AH01626: authorization result of > : granted > [Tue May 31 15:08:38.088303 2016] [core:trace3] [pid 49] request.c(293): > [client ::1:54638] request authorized without authentication by > access_checker_ex hook: /headers.php > [Tue May 31 15:08:38.088403 2016] [proxy:trace2] [pid 49] > proxy_util.c(1976): [client ::1:54638] *: using default reverse proxy > worker for fcgi:// > 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php (no keepalive) > [Tue May 31 15:08:38.088410 2016] [proxy:debug] [pid 49] > mod_proxy.c(1163): [client ::1:54638] AH01143: Running scheme fcgi handler > (attempt 0) > [Tue May 31 15:08:38.088418 2016] [proxy_ajp:debug] [pid 49] > mod_proxy_ajp.c(710): [client ::1:54638] AH00894: declining URL fcgi:// > 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php > [Tue May 31 15:08:38.088426 2016] [proxy_fcgi:debug] [pid 49] > mod_proxy_fcgi.c(861): [client ::1:54638] AH01076: url: fcgi:// > 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php proxyname: > (null) proxyport: 0 > [Tue May 31 15:08:38.088430 2016] [proxy_fcgi:debug] [pid 49] > mod_proxy_fcgi.c(868): [client ::1:54638] AH01078: serving URL fcgi:// > 127.0.0.1:9000/opt/rh/httpd24/root/var/www/html/headers.php > [Tue May 31 15:08:38.088433 2016] [proxy:debug] [pid 49] > proxy_util.c(2140): AH00942: FCGI: has acquired connection for (*) > [Tue May 31 15:08:3
Re: [users@httpd] Last-Modified header overridden
Hi Luca, On Mon, May 30, 2016 at 1:45 PM, Luca Toscano wrote: > Hi Manuel! > > 2016-05-27 14:28 GMT+02:00 Vacelet, Manuel : > >> 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: >> > >> 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
[users@httpd] Re: Last-Modified header overridden
Hi, FWIW, I submitted a bug to the Centos project: https://bugs.centos.org/view.php?id=10940 On Fri, May 27, 2016 at 2:28 PM, Vacelet, Manuel wrote: > 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: > > 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. > > Note: I tested with nginx instead of apache, nginx doesn't modify the > header so it's not an issue with the php/fpm part. > > Any idea ? >
[users@httpd] Last-Modified header overridden
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:
