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 17504200AF6 for ; Sat, 11 Jun 2016 11:54:53 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 15DC6160A34; Sat, 11 Jun 2016 09:54:53 +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 B305A160A1A for ; Sat, 11 Jun 2016 11:54:51 +0200 (CEST) Received: (qmail 11019 invoked by uid 500); 11 Jun 2016 09:54:50 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 10999 invoked by uid 99); 11 Jun 2016 09:54:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Jun 2016 09:54:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 462ED1A01A6; Sat, 11 Jun 2016 09:54:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, 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: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id PLkGdBHzH287; Sat, 11 Jun 2016 09:54:47 +0000 (UTC) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id DA0A55F2C3; Sat, 11 Jun 2016 09:54:46 +0000 (UTC) Received: by mail-lf0-f54.google.com with SMTP id f6so38144209lfg.0; Sat, 11 Jun 2016 02:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gAS1085a5IHUwyJ5SV4gUccwZ0K7qcgEPNi34JdIzrg=; b=XjYTgALnSEOpz/h7sY+O03PgaagADtaYbeJM07TiXpxg70co/VR0JZolOzKOppccbI XGLbChuroxvFWngA9HZSu6BTrxD5frirxE0BVj8+AC8Av9SD7dLe+6RQAep/4X6G6yPc KpuignS7v0ZQvAuctY2YeCZgemNwt2Wy3k0gQ4UwgUL5hw9P5u63oZ8F5+L8/3EzqYUT Tq9B/naXRYjTI3nQR6AcLvjCbbQXmYn+ag12D/fGG+5fAuDh2vPfeNW+IomD3cSUTMh4 DLNZiNhrnVgujVJ8Vv46Bgjnbxj1YU2TsHb5qp2jPOml9atTi/UGxlYpzBx8I4sPcuaf siWA== 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=gAS1085a5IHUwyJ5SV4gUccwZ0K7qcgEPNi34JdIzrg=; b=irEwyd+FegQh13xG77YSK3WPjGMOWcXNzzk5bvDi90oG1vtcvQU189/10JAwV3copJ FLNlUr9YwWNcJVCugrNi9NoqWsOf0ziUMn3zfKOz3CDvcJzjx6jzdmBfH4tIGw+uJzWu QiIBfWbmcSEhuBBGLajwXdq1mXV/dawtZxN1NacyKm8WFHWcYbeK3hjBhHRQ3vy5W7iL 8WA22OgmDRhBWJW+GJ4pssN/wpCoR5wYzAeRMRRvY31IeUlhukATmLvZgfDgg6qjI+hU fUfWGLh/3+oUvSRPGQ6uPA8S98MV4AUV+bCdH9T7GIPHLhuxBClPoaIx3xDTZuk1pxCw 3Xyg== X-Gm-Message-State: ALyK8tKA9AVLwfoICURsIKx0CDH2ImDc7PsHiEwaa8X/UQhcy70J73WooJom6W87xLyHQ+OXlYFpyYjL/WDBfQ== X-Received: by 10.25.133.135 with SMTP id h129mr1798572lfd.28.1465638878777; Sat, 11 Jun 2016 02:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.78.17 with HTTP; Sat, 11 Jun 2016 02:54:37 -0700 (PDT) In-Reply-To: References: From: Luca Toscano Date: Sat, 11 Jun 2016 11:54:37 +0200 Message-ID: Subject: Re: [users@httpd] Last-Modified header overridden To: Apache HTTP Server Development List Cc: users@httpd.apache.org Content-Type: multipart/alternative; boundary=001a113fbc66bd17290534fda4ee archived-at: Sat, 11 Jun 2016 09:54:53 -0000 --001a113fbc66bd17290534fda4ee Content-Type: text/plain; charset=UTF-8 2016-06-09 16:07 GMT+02:00 Luca Toscano : > > > 2016-06-08 13:42 GMT+02:00 Luca Toscano : > >> [+devs] >> >> 2016-06-07 23:02 GMT+02:00 Luca Toscano : >> >>> >>> >>> 2016-06-07 10:55 GMT+02:00 Vacelet, Manuel : >>> >>>> >>>> >>>> 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 >>>>>> 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 >>> >>> Any thoughts by other readers of the email list? >>> >> >> More specifically, the following patch let the "foo" Last-Modified header >> to be returned instead of unix epoch: >> >> --- server/util_script.c (revision 1747375) >> +++ server/util_script.c (working copy) >> @@ -665,8 +665,13 @@ >> * pass it on blindly because of restrictions on future 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) { >> + ap_update_mtime(r, last_modified_date); >> + ap_set_last_modified(r); >> + } else { >> + apr_table_set(r->headers_out, w, l); >> + } >> } >> else if (!strcasecmp(w, "Set-Cookie")) { >> apr_table_add(cookie_table, w, l); >> >> Omitting the "else" branch will force httpd to drop anything that is not >> a date in Last-Modified (like 'foo'). Of course this patch is only a proof >> of concept, it is not meant to be the final solution :) >> >> Reading https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html I am not >> sure what would be the best course of action. >> >> I added the httpd-dev mailing list to get some opinion. Steps to repro >> are contained in https://bugs.centos.org/view.php?id=10940 >> >> > More specific: > > ap_scan_script_header_err_core_ex in server/utils.c (that should be used > by mod-proxy-fcgi) checks headers returned from fcgi scripts and translates > non RFC compliant Last-Modified header values to unix epoch. For example, > Last-Modified: foo is returned to the client as Last-Modified: Thu, 01 Jan > 1970 00:00:00 GMT. > > What would be the correct behavior in this case? Not returning any > Last-Modified to the client (and maybe logging an error/warning?), > returning the non compliant value as it is, returning Last-Modified: now(), > other? > > Any help would really be appreciated :) > After a chat in #httpd-dev I am proposing this trunk patch: Index: server/util_script.c =================================================================== --- server/util_script.c (revision 1747855) +++ server/util_script.c (working copy) @@ -662,11 +662,19 @@ } /* * 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 (!ap_cstr_casecmp(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) { + ap_update_mtime(r, apr_date_parse_http(l)); + ap_set_last_modified(r); + } + else { + if (APLOGrtrace1(r)) + ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r, + "Invalid header value: Last-Modified: '%s'", l); + } } else if (!ap_cstr_casecmp(w, "Set-Cookie")) { apr_table_add(cookie_table, w, l); Tested also on 2.4.x, it correctly drops (and log) headers like 'Last-Modified: foo'. This would be my first commit outside the documentation realm so any feedback would be really great. In case nobody is against this patch I'll submit a trunk commit during the next days. Thanks! Luca --001a113fbc66bd17290534fda4ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2016-06-09 16:07 GMT+02:00 Luca Toscano <toscano.luca@gmail.com= >:


2016-06-08 = 13:42 GMT+02:00 Luca Toscano <toscano.luca@gmail.com>:<= br>
[+devs]
=
2016-06-07 23:02 GMT+02:00 Luca To= scano <toscano.luca@gmail.com>:


2016-06-07 10:55 GMT+02:00 Vacelet, Manuel <= ;manuel.vac= elet@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>
Any thoughts by other readers of the em= ail list?=C2=A0

Mor= e specifically, the following patch let the "foo" Last-Modified h= eader to be returned instead of unix epoch:

--- se= rver/util_script.c (revision 17= 47375)
+++ server/util_script.c (working copy)
@@ -665,8 +665,13 @@
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 * pass it on blindly because of restrictions on= future values.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (!strcasecmp(w, "Last-Modifi= ed")) {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ap_update= _mtime(r, apr_date_parse_http(l));
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ap_set_last_modified(r);
+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0apr_time_t last_modified_date =3D apr_date_parse_http(l);<= /div>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (last_modified_date= ) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ap_u= pdate_mtime(r, last_modified_date);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0ap_set_last_modified(r);
+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else {
+ =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apr_table_set(r->headers_out, w, l);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else = if (!strcasecmp(w, "Set-Cookie")) {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apr_table_add(cookie_table, w, l);=C2=A0

Omitting the "else" branch will force httpd= to drop anything that is not a date in Last-Modified (like 'foo').= Of course this patch is only a proof of concept, it is not meant to be the= final solution :)

Reading https://www.= w3.org/Protocols/rfc2616/rfc2616-sec14.html I am not sure what would be= the best course of action.

I added the httpd-dev = mailing list to get some opinion. Steps to repro are contained in https://= bugs.centos.org/view.php?id=3D10940=C2=A0


More specific:=C2=A0<= /div>

ap_scan_script_header_err_core_ex in server/utils.= c (that should be used by mod-proxy-fcgi) checks headers returned from fcgi= scripts and translates non RFC compliant Last-Modified header values to un= ix epoch. For example, Last-Modified: foo is returned to the client as Last= -Modified: Thu, 01 Jan 1970 00:00:00 GMT.=C2=A0

What would be the correct behavior in this case? Not returning any Last-M= odified to the client (and maybe logging an error/warning?), returning the = non compliant value as it is, returning Last-Modified: now(), other?
<= div>
Any help would really be appreciated :)
=

=C2=A0After a chat in #h= ttpd-dev I am proposing this trunk patch:

Index: s= erver/util_script.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
--- server/util_script.c (revision 1747855)
+++ server/util_script.c (working copy)
@@ -= 662,11 +662,19 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 * If the script gave us a Last-Modified header, we can't just
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 * pass it on blindly because of restr= ictions on future values.
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 * pass it= on blindly because of restrictions on future or invalid values.
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0else if (!ap_cstr_casecmp(w, "Last-Modified")) {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ap_update_mtime(r, apr_date_par= se_http(l));
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ap_set_la= st_modified(r);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apr_ti= me_t last_modified_date =3D apr_date_parse_http(l);
+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (last_modified_date) {
+ =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ap_update_mtime(r, apr_dat= e_parse_http(l));
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ap_set_last_modified(r);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else {<= /div>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (APLO= Grtrace1(r))
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r,
= + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Invalid header value: Last-Mod= ified: '%s'", l);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (!ap_cstr_casecmp(w, "Set-Cookie&qu= ot;)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0apr_table= _add(cookie_table, w, l);=C2=A0


Tes= ted also on 2.4.x, it correctly drops (and log) headers like 'Last-Modi= fied: foo'. This =C2=A0would be my first commit outside the documentati= on realm so any feedback would be really great. In case nobody is against t= his patch I'll submit a trunk commit during the next days.
Thanks!

Luca=C2=A0

--001a113fbc66bd17290534fda4ee--