Mailing List Archive

Hi Christophe,

Thanks a lot for spotting this, good catch. I haven't proposed a
backport in months and the first one ends up in a little mess, really
sorry :(

So judging from the diff, I think that it is missing the last two commits:

http://svn.apache.org/viewvc?view=revision&revision=1879253
http://svn.apache.org/viewvc?view=revision&revision=1879348

The svn merge command contains a typo (didn't see it when committing),
namely r1879348 at the end (extra r), maybe this was the issue?

svn merge -c 1748379,1750747,1750749,1750953,1751138,1751139,1751139,1757818,1879253,r1879348
^/httpd/httpd/trunk .

Luca

On Wed, Jul 8, 2020 at 10:11 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> Le 08/07/2020 à 13:39, minfrin@apache.org a écrit :
> > Author: minfrin
> > Date: Wed Jul 8 11:39:12 2020
> > New Revision: 1879641
> >
> > URL: http://svn.apache.org/viewvc?rev=1879641&view=rev
> > Log:
> > *) core: Drop an invalid Last-Modified header value coming
> > from a (F)CGI script instead of replacing it with Unix epoch.
> > Warn the users about Last-Modified header value replacements
> > and violations of the RFC.
> > trunk patch: http://svn.apache.org/r1748379
> > http://svn.apache.org/r1750747
> > http://svn.apache.org/r1750749
> > http://svn.apache.org/r1750953
> > http://svn.apache.org/r1751138
> > http://svn.apache.org/r1751139
> > http://svn.apache.org/r1751147
> > http://svn.apache.org/r1757818
> > http://svn.apache.org/r1879253
> > http://svn.apache.org/r1879348
> > 2.4.x: trunk patches work, final view:
> > http://home.apache.org/~elukey/httpd-2.4.x-core-last_modified_tz_logging.patch
> > svn merge -c 1748379,1750747,1750749,1750953,1751138,1751139,1751139,1757818,1879253,r1879348 ^/httpd/httpd/trunk .
> > The code has been tested with a simple PHP script returning different Last-Modified
> > headers (GMT now, GMT now Europe/Paris, GMT tomorrow, GMT yesterday, PST now).
> > +1: elukey, jorton, jim
> > jorton: +1 though I'd say log at WARN or INFO for the APR_BAD_DATE case
> > rather than "silently" (at normal log-level) dropping the parsed header?
> > [.also nit: wrapping a lone ap_log_rerror(,APLOG_X) call in
> > if (APLOGrX(..) is unnecessary/redundant]
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/ (props changed)
> > httpd/httpd/branches/2.4.x/CHANGES
> > httpd/httpd/branches/2.4.x/STATUS
> > httpd/httpd/branches/2.4.x/server/util_script.c
> >
> > Propchange: httpd/httpd/branches/2.4.x/
> > ------------------------------------------------------------------------------
> > Merged /httpd/httpd/trunk:r1748379
> >
> > Modified: httpd/httpd/branches/2.4.x/CHANGES
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1879641&r1=1879640&r2=1879641&view=diff
> > ==============================================================================
> > --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
> > +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Wed Jul 8 11:39:12 2020
> > @@ -1,6 +1,10 @@
> > -*- coding: utf-8 -*-
> > Changes with Apache 2.4.44
> >
> > + *) core: Drop an invalid Last-Modified header value coming
> > + from a FCGI/CGI script instead of replacing it with Unix epoch.
> > + [Luca Toscano]
> > +
> > *) Add support for strict content-length parsing through addition of
> > ap_parse_strict_length() [Yann Ylavic]
> >
> >
> > Modified: httpd/httpd/branches/2.4.x/STATUS
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1879641&r1=1879640&r2=1879641&view=diff
> > ==============================================================================
> > --- httpd/httpd/branches/2.4.x/STATUS (original)
> > +++ httpd/httpd/branches/2.4.x/STATUS Wed Jul 8 11:39:12 2020
> > @@ -135,31 +135,6 @@ RELEASE SHOWSTOPPERS:
> > PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
> > [ start all new proposals below, under PATCHES PROPOSED. ]
> >
> > - *) core: Drop an invalid Last-Modified header value coming
> > - from a (F)CGI script instead of replacing it with Unix epoch.
> > - Warn the users about Last-Modified header value replacements
> > - and violations of the RFC.
> > - trunk patch: http://svn.apache.org/r1748379
> > - http://svn.apache.org/r1750747
> > - http://svn.apache.org/r1750749
> > - http://svn.apache.org/r1750953
> > - http://svn.apache.org/r1751138
> > - http://svn.apache.org/r1751139
> > - http://svn.apache.org/r1751147
> > - http://svn.apache.org/r1757818
> > - http://svn.apache.org/r1879253
> > - http://svn.apache.org/r1879348
> > - 2.4.x: trunk patches work, final view:
> > - http://home.apache.org/~elukey/httpd-2.4.x-core-last_modified_tz_logging.patch
> > - svn merge -c 1748379,1750747,1750749,1750953,1751138,1751139,1751139,1757818,1879253,r1879348 ^/httpd/httpd/trunk .
> > - The code has been tested with a simple PHP script returning different Last-Modified
> > - headers (GMT now, GMT now Europe/Paris, GMT tomorrow, GMT yesterday, PST now).
> > - +1: elukey, jorton, jim
> > - jorton: +1 though I'd say log at WARN or INFO for the APR_BAD_DATE case
> > - rather than "silently" (at normal log-level) dropping the parsed header?
> > - [.also nit: wrapping a lone ap_log_rerror(,APLOG_X) call in
> > - if (APLOGrX(..) is unnecessary/redundant]
> > -
> > *) mod_http2: connection terminology renamed to master/secondary.
> > trunk patch: http://svn.apache.org/r1878926
> > http://svn.apache.org/r1879156
> >
> > Modified: httpd/httpd/branches/2.4.x/server/util_script.c
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/util_script.c?rev=1879641&r1=1879640&r2=1879641&view=diff
> > ==============================================================================
> > --- httpd/httpd/branches/2.4.x/server/util_script.c (original)
> > +++ httpd/httpd/branches/2.4.x/server/util_script.c Wed Jul 8 11:39:12 2020
> > @@ -669,11 +669,19 @@ AP_DECLARE(int) ap_scan_script_header_er
> > }
> > /*
> > * If the script gave us a Last-Modified header, we can't just
> > - * pass it on blindly because of restrictions on future values.
> > + * pass it on blindly because of restrictions on future or invalid values.
> > */
> > else if (!strcasecmp(w, "Last-Modified")) {
> > - ap_update_mtime(r, apr_date_parse_http(l));
> > - ap_set_last_modified(r);
> > + apr_time_t last_modified_date = apr_date_parse_http(l);
> > + if (last_modified_date != APR_DATE_BAD) {
> > + ap_update_mtime(r, last_modified_date);
> > + ap_set_last_modified(r);
> > + }
> > + else {
> > + if (APLOGrtrace1(r))
> > + ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r,
> > + "Ignored invalid header value: Last-Modified: '%s'", l);
> > + }
> > }
> > else if (!strcasecmp(w, "Set-Cookie")) {
> > apr_table_add(cookie_table, w, l);
> >
> >
> >
> Hi,
>
> I don't know if intentional or not, but the patch applied is not the one
> from a.o/~elukey/httpd-2.4.x-core-last_modified_tz_logging.patch
>
> CJ
>

Hi everybody,

getting back on this. I checked mergeinfo and r1879253 r1879348 are
not listed, what is the best path forward to fix this? (Asking because
I have never merged from trunk, and I am not sure what is the best
path forward).

Thanks in advance,

Luca

On Wed, Jul 8, 2020 at 11:20 PM Luca Toscano <toscano.luca@gmail.com> wrote:
>
> Hi Christophe,
>
> Thanks a lot for spotting this, good catch. I haven't proposed a
> backport in months and the first one ends up in a little mess, really
> sorry :(
>
> So judging from the diff, I think that it is missing the last two commits:
>
> http://svn.apache.org/viewvc?view=revision&revision=1879253
> http://svn.apache.org/viewvc?view=revision&revision=1879348
>
> The svn merge command contains a typo (didn't see it when committing),
> namely r1879348 at the end (extra r), maybe this was the issue?
>
> svn merge -c 1748379,1750747,1750749,1750953,1751138,1751139,1751139,1757818,1879253,r1879348
> ^/httpd/httpd/trunk .
>
> Luca
>
> On Wed, Jul 8, 2020 at 10:11 PM Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> wrote:
> >
> > Le 08/07/2020 à 13:39, minfrin@apache.org a écrit :
> > > Author: minfrin
> > > Date: Wed Jul 8 11:39:12 2020
> > > New Revision: 1879641
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1879641&view=rev
> > > Log:
> > > *) core: Drop an invalid Last-Modified header value coming
> > > from a (F)CGI script instead of replacing it with Unix epoch.
> > > Warn the users about Last-Modified header value replacements
> > > and violations of the RFC.
> > > trunk patch: http://svn.apache.org/r1748379
> > > http://svn.apache.org/r1750747
> > > http://svn.apache.org/r1750749
> > > http://svn.apache.org/r1750953
> > > http://svn.apache.org/r1751138
> > > http://svn.apache.org/r1751139
> > > http://svn.apache.org/r1751147
> > > http://svn.apache.org/r1757818
> > > http://svn.apache.org/r1879253
> > > http://svn.apache.org/r1879348
> > > 2.4.x: trunk patches work, final view:
> > > http://home.apache.org/~elukey/httpd-2.4.x-core-last_modified_tz_logging.patch
> > > svn merge -c 1748379,1750747,1750749,1750953,1751138,1751139,1751139,1757818,1879253,r1879348 ^/httpd/httpd/trunk .
> > > The code has been tested with a simple PHP script returning different Last-Modified
> > > headers (GMT now, GMT now Europe/Paris, GMT tomorrow, GMT yesterday, PST now).
> > > +1: elukey, jorton, jim
> > > jorton: +1 though I'd say log at WARN or INFO for the APR_BAD_DATE case
> > > rather than "silently" (at normal log-level) dropping the parsed header?
> > > [.also nit: wrapping a lone ap_log_rerror(,APLOG_X) call in
> > > if (APLOGrX(..) is unnecessary/redundant]
> > >
> > > Modified:
> > > httpd/httpd/branches/2.4.x/ (props changed)
> > > httpd/httpd/branches/2.4.x/CHANGES
> > > httpd/httpd/branches/2.4.x/STATUS
> > > httpd/httpd/branches/2.4.x/server/util_script.c
> > >
> > > Propchange: httpd/httpd/branches/2.4.x/
> > > ------------------------------------------------------------------------------
> > > Merged /httpd/httpd/trunk:r1748379
> > >
> > > Modified: httpd/httpd/branches/2.4.x/CHANGES
> > > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1879641&r1=1879640&r2=1879641&view=diff
> > > ==============================================================================
> > > --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
> > > +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Wed Jul 8 11:39:12 2020
> > > @@ -1,6 +1,10 @@
> > > -*- coding: utf-8 -*-
> > > Changes with Apache 2.4.44
> > >
> > > + *) core: Drop an invalid Last-Modified header value coming
> > > + from a FCGI/CGI script instead of replacing it with Unix epoch.
> > > + [Luca Toscano]
> > > +
> > > *) Add support for strict content-length parsing through addition of
> > > ap_parse_strict_length() [Yann Ylavic]
> > >
> > >
> > > Modified: httpd/httpd/branches/2.4.x/STATUS
> > > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1879641&r1=1879640&r2=1879641&view=diff
> > > ==============================================================================
> > > --- httpd/httpd/branches/2.4.x/STATUS (original)
> > > +++ httpd/httpd/branches/2.4.x/STATUS Wed Jul 8 11:39:12 2020
> > > @@ -135,31 +135,6 @@ RELEASE SHOWSTOPPERS:
> > > PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
> > > [ start all new proposals below, under PATCHES PROPOSED. ]
> > >
> > > - *) core: Drop an invalid Last-Modified header value coming
> > > - from a (F)CGI script instead of replacing it with Unix epoch.
> > > - Warn the users about Last-Modified header value replacements
> > > - and violations of the RFC.
> > > - trunk patch: http://svn.apache.org/r1748379
> > > - http://svn.apache.org/r1750747
> > > - http://svn.apache.org/r1750749
> > > - http://svn.apache.org/r1750953
> > > - http://svn.apache.org/r1751138
> > > - http://svn.apache.org/r1751139
> > > - http://svn.apache.org/r1751147
> > > - http://svn.apache.org/r1757818
> > > - http://svn.apache.org/r1879253
> > > - http://svn.apache.org/r1879348
> > > - 2.4.x: trunk patches work, final view:
> > > - http://home.apache.org/~elukey/httpd-2.4.x-core-last_modified_tz_logging.patch
> > > - svn merge -c 1748379,1750747,1750749,1750953,1751138,1751139,1751139,1757818,1879253,r1879348 ^/httpd/httpd/trunk .
> > > - The code has been tested with a simple PHP script returning different Last-Modified
> > > - headers (GMT now, GMT now Europe/Paris, GMT tomorrow, GMT yesterday, PST now).
> > > - +1: elukey, jorton, jim
> > > - jorton: +1 though I'd say log at WARN or INFO for the APR_BAD_DATE case
> > > - rather than "silently" (at normal log-level) dropping the parsed header?
> > > - [.also nit: wrapping a lone ap_log_rerror(,APLOG_X) call in
> > > - if (APLOGrX(..) is unnecessary/redundant]
> > > -
> > > *) mod_http2: connection terminology renamed to master/secondary.
> > > trunk patch: http://svn.apache.org/r1878926
> > > http://svn.apache.org/r1879156
> > >
> > > Modified: httpd/httpd/branches/2.4.x/server/util_script.c
> > > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/util_script.c?rev=1879641&r1=1879640&r2=1879641&view=diff
> > > ==============================================================================
> > > --- httpd/httpd/branches/2.4.x/server/util_script.c (original)
> > > +++ httpd/httpd/branches/2.4.x/server/util_script.c Wed Jul 8 11:39:12 2020
> > > @@ -669,11 +669,19 @@ AP_DECLARE(int) ap_scan_script_header_er
> > > }
> > > /*
> > > * If the script gave us a Last-Modified header, we can't just
> > > - * pass it on blindly because of restrictions on future values.
> > > + * pass it on blindly because of restrictions on future or invalid values.
> > > */
> > > else if (!strcasecmp(w, "Last-Modified")) {
> > > - ap_update_mtime(r, apr_date_parse_http(l));
> > > - ap_set_last_modified(r);
> > > + apr_time_t last_modified_date = apr_date_parse_http(l);
> > > + if (last_modified_date != APR_DATE_BAD) {
> > > + ap_update_mtime(r, last_modified_date);
> > > + ap_set_last_modified(r);
> > > + }
> > > + else {
> > > + if (APLOGrtrace1(r))
> > > + ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r,
> > > + "Ignored invalid header value: Last-Modified: '%s'", l);
> > > + }
> > > }
> > > else if (!strcasecmp(w, "Set-Cookie")) {
> > > apr_table_add(cookie_table, w, l);
> > >
> > >
> > >
> > Hi,
> >
> > I don't know if intentional or not, but the patch applied is not the one
> > from a.o/~elukey/httpd-2.4.x-core-last_modified_tz_logging.patch
> >
> > CJ
> >

On 7/15/20 9:06 AM, Luca Toscano wrote:
> Hi everybody,
>
> getting back on this. I checked mergeinfo and r1879253 r1879348 are
> not listed, what is the best path forward to fix this? (Asking because
> I have never merged from trunk, and I am not sure what is the best
> path forward).

Try

svn merge --record-only -c 1879253,1879348 https://svn.apache.org/repos/asf/httpd/httpd/trunk .

in a freshly svn up'ed working copy of 2.4.x.

Regards

Rüdiger

Hi Ruediger,

On Wed, Jul 15, 2020 at 10:04 AM Ruediger Pluem <rpluem@apache.org> wrote:
>
>
> On 7/15/20 9:06 AM, Luca Toscano wrote:
> > Hi everybody,
> >
> > getting back on this. I checked mergeinfo and r1879253 r1879348 are
> > not listed, what is the best path forward to fix this? (Asking because
> > I have never merged from trunk, and I am not sure what is the best
> > path forward).
>
> Try
>
> svn merge --record-only -c 1879253,1879348 https://svn.apache.org/repos/asf/httpd/httpd/trunk .
>
> in a freshly svn up'ed working copy of 2.4.x.

Thanks for the answer. IIUC the above command takes care of updating
mergeinfo with the missing revs, but the problem is (I think) that
they didn't get merged in the first place along with the others (so
they are missing from 2.4.x). Since I never merged commits into 2.4.x,
I was wondering what to do to avoid messing up the state :)

Luca

On 7/18/20 10:11 AM, Luca Toscano wrote:
> Hi Ruediger,
>
> On Wed, Jul 15, 2020 at 10:04 AM Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>
>> On 7/15/20 9:06 AM, Luca Toscano wrote:
>>> Hi everybody,
>>>
>>> getting back on this. I checked mergeinfo and r1879253 r1879348 are
>>> not listed, what is the best path forward to fix this? (Asking because
>>> I have never merged from trunk, and I am not sure what is the best
>>> path forward).
>>
>> Try
>>
>> svn merge --record-only -c 1879253,1879348 https://svn.apache.org/repos/asf/httpd/httpd/trunk .
>>
>> in a freshly svn up'ed working copy of 2.4.x.
>
> Thanks for the answer. IIUC the above command takes care of updating
> mergeinfo with the missing revs, but the problem is (I think) that
> they didn't get merged in the first place along with the others (so
> they are missing from 2.4.x). Since I never merged commits into 2.4.x,
> I was wondering what to do to avoid messing up the state :)

Good catch. The backport was incomplete as only the first of the list of revisions was backported.
Fixed in r1880060.

Regards

Rüdiger