2016-06-06 15:57 GMT+02:00 Vacelet, Manuel <manuel.vace...@enalean.com>:
> On Mon, Jun 6, 2016 at 1:36 PM, Vacelet, Manuel < > manuel.vace...@enalean.com> wrote: > >> Hi Luca >> >> On Sat, Jun 4, 2016 at 4:54 PM, Luca Toscano <toscano.l...@gmail.com> >> 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. > > 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? 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 :). Luca
