Re: T&R of 2.4.24

[William A Rowe Jr]

On Fri, Dec 9, 2016 at 8:03 AM, Jim Jagielski  wrote:

>
> > On Dec 9, 2016, at 12:20 AM, William A Rowe Jr 
> wrote:
> >
> > On Thu, Dec 8, 2016 at 12:16 PM, William A Rowe Jr 
> wrote:
> >
> > @VP Legal, is this worth an escalation? You didn't see fit to respond
> today,
> > but I think this falls under the purview of your committee, w.r.t.
> unapproved
> > release artifacts living at www.apache.org/dist/. Did you have any
> thoughts
> > or opinions one way or another?
>
> How is this different from, say, the win32 src zips or the
> complimentary binary builds?


That's an interesting question, or questions...

For starters, source aren't binaries, but of course you knew that, as our
esteemed VP, Legal.

When ASF projects convey binaries, they convey them (purportedly) based
on the current jars/wars of the dependencies (are there other dependent
projects? SVN doesn't ship binaries, and I have no clue what OpenOffice
does. Other non-java examples are few and far between.)

These are fetched up fresh from maven or whatnot, and don't have a lot of
bearing on how non-java projects do things. AIUI, those jars don't even
supplant what is already provisioned, if those are more current, unless
the manifest demands an old rev.

The prior win32 src (before I committed that to branch, not trunk, and
didn't worry our silly heads about crlf after I wrote the apr fix script)
didn't include extra artifacts, unless you count apr-iconv. And I have
deep reservations about that call, if you've seen my comments about
what citrus might bring us and lack of maintaining that BSD iconv fork.

Thanks for the redaction on the 2.4.25-deps artifact. Frankly, I would
not have helped you push that out the door without that one concession.
And mad props to JChapmion for pushing the announce, since I didn't
have ASF smtp at the ready. So as always, it was an effort of many.

Fundamental issue with pushing -deps of, say, APR 1.5.2, is that the
following week is that 1.5.3 with bug fixes is released. Is the httpd
project responsible for updating -deps? Or f' ya all, download this
package... it won't hurt you... hopefully? Believe me, I went through
all that as an httpd win32 binary distributor who bundled openssl,
so I know this specific pain-point, and sense of responsibility, and
did have to ship new interim binaries when bad things were disclosed.

I hope you sort this out in your ombudsman role, because this is the
test of whether you understand ASF responsibilities, both legally,
and in the sense of our entire ecosystem, and the will of your specific
project who had a very firm position, before you undermined it.

Cheers, and a Merry Christmas!

Bill

Re: svn commit: r1775705 - in /httpd/httpd/branches/2.2.x-merge-http-strict: ./ server/protocol.c

[William A Rowe Jr]

On Thu, Dec 22, 2016 at 6:00 PM, Yann Ylavic  wrote:

> On Thu, Dec 22, 2016 at 8:20 PM,   wrote:
> > Author: wrowe
> > Date: Thu Dec 22 19:20:25 2016
> > New Revision: 1775705
> >
> > URL: http://svn.apache.org/viewvc?rev=1775705&view=rev
> > Log:
> > Backports: r1185385
> > Submitted by: sf
> > Downgrade some more log messages indicating client errors from level
> error to
> > info. Add log messages for various reasons to return HTTP_BAD_REQUEST.
>
> Hmm, in 2.2, users are used to get an error message when httpd refuses
> the request (moreover before any module had seen the request).
>
> Is it really 2.2 material?
>
> >
> > Modified: httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x-
> merge-http-strict/server/protocol.c?rev=1775705&r1=
> 1775704&r2=1775705&view=diff
> > 
> ==
> > --- httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c
> (original)
> > +++ httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c Thu
> Dec 22 19:20:25 2016
> > @@ -702,9 +702,21 @@ static int table_do_fn_check_lengths(voi
> > "\n\n",
> > ap_escape_html(r->pool, key),
> > "\n", NULL));
> > +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, "Request header exceeds
> "
> > +  "LimitRequestFieldSize after merging: %s", key);
> >  return 0;
> >  }
> >
> > +/* get the length of the field name for logging, but no more than 80
> bytes */
> > +#define LOG_NAME_MAX_LEN 80
> > +static int field_name_len(const char *field)
> > +{
> > +const char *end = ap_strchr_c(field, ':');
> > +if (end == NULL || end - field > LOG_NAME_MAX_LEN)
> > +return LOG_NAME_MAX_LEN;
> > +return end - field;
> > +}
> > +
> >  AP_DECLARE(void) ap_get_mime_headers_core(request_rec *r,
> apr_bucket_brigade *bb)
> >  {
> >  char *last_field = NULL;
> > @@ -755,6 +767,9 @@ AP_DECLARE(void) ap_get_mime_headers_cor
> >  ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> >"Request header exceeds
> LimitRequestFieldSize: "
> >"%.*s", field_name_len(field), field);
> > +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> > +  "Request header exceeds
> LimitRequestFieldSize: "
> > +  "%.*s", field_name_len(field), field);
>
> Double logging?
>
> >  }
> >  return;
> >  }
> > @@ -786,6 +801,10 @@ AP_DECLARE(void) ap_get_mime_headers_cor
> >"Request header exceeds
> LimitRequestFieldSize "
> >"after folding: %.*s",
> >field_name_len(last_field),
> last_field);
> > +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> > +  "Request header exceeds
> LimitRequestFieldSize "
> > +  "after folding: %.*s",
> > +  field_name_len(last_field),
> last_field);
>
> Likewise?
>
> >  return;
> >  }
> >
> > @@ -811,6 +830,9 @@ AP_DECLARE(void) ap_get_mime_headers_cor
> >  apr_table_setn(r->notes, "error-notes",
> > "The number of request header fields
> "
> > "exceeds this server's limit.");
> > +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> > +  "Number of request headers exceeds "
> > +  "LimitRequestFields");
> >  return;
> >  }
> >
> > @@ -829,6 +851,10 @@ AP_DECLARE(void) ap_get_mime_headers_cor
> >"separator: %.*s",
> (int)LOG_NAME_MAX_LEN,
> >last_field);
> >
> > +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> > +  "Request header field is missing ':' "
> > +  "separator: %.*s",
> (int)LOG_NAME_MAX_LEN,
> > +  last_field);
>
> Likewise?
>
> >  return;
> >  }
>

Yes, doubled merge. Believe I have these cleaned up in r1775774.

Re: Frequent wake-ups for mpm_event

[Yann Ylavic]

Hi Stefan,

On Tue, Dec 20, 2016 at 1:52 PM, Stefan Priebe - Profihost AG
 wrote:
>
> Today i had another server giving no answers to any requests. apache
> fullstatus did not respond.

Since v5 of the patch, I committed another related change in trunk,
namely: http://svn.apache.org/r1774538
It's about lingering keepalive connections on graceful restart which
may not cause a wakeup.
Does it help?

>
> gdb bt shows this for all httpd childs:

These backtraces are the ones of the main thread, probably not the culprit.
What does "thread apply all bt" say?

Regards,
Yann.

Re: svn commit: r1775696 - /httpd/httpd/branches/2.2.x-merge-http-strict/

[William A Rowe Jr]

On Thu, Dec 22, 2016 at 5:50 PM, Yann Ylavic  wrote:

> On Thu, Dec 22, 2016 at 7:45 PM,   wrote:
> > Author: wrowe
> > Date: Thu Dec 22 18:45:59 2016
> > New Revision: 1775696
> >
> > URL: http://svn.apache.org/viewvc?rev=1775696&view=rev
> > Log:
> > Backports: r1100511
> > Submitted by: covener
> > use APR_STATUS_IS_TIMEUP() instead of direct comparison with APR_TIMEUP.
> >
> > Modified:
> > httpd/httpd/branches/2.2.x-merge-http-strict/   (props changed)
>
> No (non-props) change?
>

Red herring, it came into 2.2.x branch through the original commit, from
the svn blame on the 2.2.x-merge file.

Re: svn commit: r1775705 - in /httpd/httpd/branches/2.2.x-merge-http-strict: ./ server/protocol.c

[Yann Ylavic]

On Thu, Dec 22, 2016 at 8:20 PM,   wrote:
> Author: wrowe
> Date: Thu Dec 22 19:20:25 2016
> New Revision: 1775705
>
> URL: http://svn.apache.org/viewvc?rev=1775705&view=rev
> Log:
> Backports: r1185385
> Submitted by: sf
> Downgrade some more log messages indicating client errors from level error to
> info. Add log messages for various reasons to return HTTP_BAD_REQUEST.

Hmm, in 2.2, users are used to get an error message when httpd refuses
the request (moreover before any module had seen the request).

Is it really 2.2 material?

>
> Modified: httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c?rev=1775705&r1=1775704&r2=1775705&view=diff
> ==
> --- httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c (original)
> +++ httpd/httpd/branches/2.2.x-merge-http-strict/server/protocol.c Thu Dec 22 
> 19:20:25 2016
> @@ -702,9 +702,21 @@ static int table_do_fn_check_lengths(voi
> "\n\n",
> ap_escape_html(r->pool, key),
> "\n", NULL));
> +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, "Request header exceeds "
> +  "LimitRequestFieldSize after merging: %s", key);
>  return 0;
>  }
>
> +/* get the length of the field name for logging, but no more than 80 bytes */
> +#define LOG_NAME_MAX_LEN 80
> +static int field_name_len(const char *field)
> +{
> +const char *end = ap_strchr_c(field, ':');
> +if (end == NULL || end - field > LOG_NAME_MAX_LEN)
> +return LOG_NAME_MAX_LEN;
> +return end - field;
> +}
> +
>  AP_DECLARE(void) ap_get_mime_headers_core(request_rec *r, apr_bucket_brigade 
> *bb)
>  {
>  char *last_field = NULL;
> @@ -755,6 +767,9 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>  ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
>"Request header exceeds LimitRequestFieldSize: 
> "
>"%.*s", field_name_len(field), field);
> +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> +  "Request header exceeds LimitRequestFieldSize: 
> "
> +  "%.*s", field_name_len(field), field);

Double logging?

>  }
>  return;
>  }
> @@ -786,6 +801,10 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>"Request header exceeds 
> LimitRequestFieldSize "
>"after folding: %.*s",
>field_name_len(last_field), last_field);
> +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> +  "Request header exceeds 
> LimitRequestFieldSize "
> +  "after folding: %.*s",
> +  field_name_len(last_field), last_field);

Likewise?

>  return;
>  }
>
> @@ -811,6 +830,9 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>  apr_table_setn(r->notes, "error-notes",
> "The number of request header fields "
> "exceeds this server's limit.");
> +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> +  "Number of request headers exceeds "
> +  "LimitRequestFields");
>  return;
>  }
>
> @@ -829,6 +851,10 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>"separator: %.*s", (int)LOG_NAME_MAX_LEN,
>last_field);
>
> +ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
> +  "Request header field is missing ':' "
> +  "separator: %.*s", (int)LOG_NAME_MAX_LEN,
> +  last_field);

Likewise?

>  return;
>  }

Re: svn commit: r1775696 - /httpd/httpd/branches/2.2.x-merge-http-strict/

[Yann Ylavic]

On Thu, Dec 22, 2016 at 7:45 PM,   wrote:
> Author: wrowe
> Date: Thu Dec 22 18:45:59 2016
> New Revision: 1775696
>
> URL: http://svn.apache.org/viewvc?rev=1775696&view=rev
> Log:
> Backports: r1100511
> Submitted by: covener
> use APR_STATUS_IS_TIMEUP() instead of direct comparison with APR_TIMEUP.
>
> Modified:
> httpd/httpd/branches/2.2.x-merge-http-strict/   (props changed)

No (non-props) change?

Re: svn commit: r1775752 - /httpd/httpd/branches/2.2.x-merge-http-strict/

[Eric Covener]

No files showed up in commit

On Thu, Dec 22, 2016 at 5:08 PM,   wrote:
> Author: wrowe
> Date: Thu Dec 22 22:08:05 2016
> New Revision: 1775752
>
> URL: http://svn.apache.org/viewvc?rev=1775752&view=rev
> Log:
> Backports: r172754c
> Submitted by: rpluem
> Ensure that proto_num and protocol is set in another "error out early" edge
> case. This can happen with invalid CONNECT requests as described in the PR.
> PR: 58929
>
>
> Modified:
> httpd/httpd/branches/2.2.x-merge-http-strict/   (props changed)
>
> Propchange: httpd/httpd/branches/2.2.x-merge-http-strict/
> --
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Thu Dec 22 22:08:05 2016
> @@ -1,2 +1,3 @@
> +/httpd/httpd/branches/2.2.x:1727544
>  
> /httpd/httpd/branches/2.4.x:138,159,1648845,1649003,1681034,1682929,1682939
>  
> /httpd/httpd/trunk:290940,395552,417988,451572,501364,583817,583830,611483,630858,639005,639010,647395,657354,657459,660461,660566,664330,678761,680082,681190,682369,683626,685112,686805,686809,687099,687754,693120,693392,693727-693728,696006,697093,706318,707163,708902,711421,713575,719357,720250,729316-729317,729586,732414,732504,732816,732832,733127,733134,733218-733219,734710,743589,755190,756671,756675,756678,756683,757741,761329,763394,764239,768535,769809,771587,771610,776325,777042,777091,778438-778439,778531,778942,780648,780655,780692,780697,780699,785457,785661,790587,803704,819480,823536,823563,834378,835046,891282,892678,892808,900022,932791,942209,952823,953311,955966,979120,981084,992625,1026743,1031551,1040304,1040373,1057372,1058192,1070096,1082189,1082196,1090645,1100511,1172732,1178566,1185385,1188745,1200040,1200372,1200374,1213380,1213391,1222335,1223048,1231446,1237407,1244211,1294306,1299738,1300171,130,1308862,1327036,1327080,1328133,1328325-1328326,13453
>  
> 19,1348656,1349905,1352911-1352912,1363183,1363186,1366344,1367778,1368131,1368396,1369568,1392347,1395225,1398066,1400700,1407004,1407088,1407528,1408402,1410681,1413732,1414094,1416889,1418752,1422234,1422253,1433613,1435178,1447426,1470940,1475878,1476604,1476621,1476642,1476644-1476645,1477530,1484852,1485409,1485668,1490994,1493330,1496429,1500323,1504276,1506714,1509872,1509875,1514215,1524192,1524770,1526168,1526189,1527291,1527295,1527925,1528718,1529559,1529988,1529991,1531505,1532816,1551685,1551714,1552227,1553204,1554276,1554281,1555240,155,1556428,1563420,1572092,1572198,1572543,1572611,1572630,1572655,1572663,1572668-1572671,1572896,1572911,1572967,1573224,1573229,1575400,1585090,1586745,1587594,1587639,1588851,1590509,1603156,1604353,1610207,1610311,1610491,1610501,1611165,1611169,1620932,1621453,1643537,1643543,1648840,1649001,1649043,1650310,1650320,1652929,1653997,1657897,1658765,1663647,1664205,1665215,1665218,1665625,1665721,1666363,1674056,1675533,1676654,16
>  
> 77462,1679182,1679470,1680895,1680900,1680942,1681037,1682923,1682937,1684513,1685345,1685347,1685349-1685350,1688274,1688536,1688538
>
>



-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1769669 [2/2] - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ docs/manual/ docs/manual/mod/ include/ server/

[William A Rowe Jr]

On Thu, Dec 22, 2016 at 11:37 AM, Rainer Jung 
wrote:

> Am 22.12.2016 um 18:25 schrieb William A Rowe Jr:
>
>> On Thu, Dec 22, 2016 at 9:29 AM, Eric Covener > > wrote:
>>
>> I think the log severity changes below could use some eyes, especially
>> in context of 2.2.  Are these lowered because they're redundant?  I
>> haven't yet looked.
>>
>> I am tempted to leave the old severities for 2.2 and wait and see if
>> it's confusing in 2.4 (should not have to enable DEBUG to see the
>> cause of a 400 error)
>>
>>
>> Log severity is lowered because successfully throwing off a (generally
>> deliberately) bad request is of no interest to an operator at loglevel
>> error/warn, any more than any successful request is of interest.
>>
>> This is just log pollution. There is no action for the operator to take.
>>
>
> Hmmm, but if it isn't about a deliberately bad request but a bad client,
> the admin could consider setting "HttpProtocolOptions Unsafe" (and now get
> what he asked for. I must admit, I didn't check whether the log lines in
> question are in code areas which are controlled by HttpProtocolOptions or
> not.
>

That's true. However, every admin/operator knows that if the app dev team
or users are complaining that the request doesn't work, the first thing any
admin does is enable loglevel debug to see what's going on.

The CTL's aren't override-able (see the security reports 2.4 detailed
description) by our group concensus, and my UnsafeWhitespace proposal was
rejected. But there is still information at debug level to know what sort
of problem occurred without breaking out wireshark first.

Once that is sorted, it's still noise and needs to be disabled again. The
broken clients will be the very odd exception, not a rule.

Re: svn commit: r1769669 [2/2] - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ docs/manual/ docs/manual/mod/ include/ server/

[Rainer Jung]

Am 22.12.2016 um 18:25 schrieb William A Rowe Jr:

On Thu, Dec 22, 2016 at 9:29 AM, Eric Covener mailto:cove...@gmail.com>> wrote:

I think the log severity changes below could use some eyes, especially
in context of 2.2.  Are these lowered because they're redundant?  I
haven't yet looked.

I am tempted to leave the old severities for 2.2 and wait and see if
it's confusing in 2.4 (should not have to enable DEBUG to see the
cause of a 400 error)


Log severity is lowered because successfully throwing off a (generally
deliberately) bad request is of no interest to an operator at loglevel
error/warn, any more than any successful request is of interest.

This is just log pollution. There is no action for the operator to take.


Hmmm, but if it isn't about a deliberately bad request but a bad client, 
the admin could consider setting "HttpProtocolOptions Unsafe" (and now 
get what he asked for. I must admit, I didn't check whether the log 
lines in question are in code areas which are controlled by 
HttpProtocolOptions or not.


Regards,

Rainer

Re: svn commit: r1769669 [2/2] - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ docs/manual/ docs/manual/mod/ include/ server/

[William A Rowe Jr]

On Thu, Dec 22, 2016 at 9:29 AM, Eric Covener  wrote:

> I think the log severity changes below could use some eyes, especially
> in context of 2.2.  Are these lowered because they're redundant?  I
> haven't yet looked.
>
> I am tempted to leave the old severities for 2.2 and wait and see if
> it's confusing in 2.4 (should not have to enable DEBUG to see the
> cause of a 400 error)


Log severity is lowered because successfully throwing off a (generally
deliberately) bad request is of no interest to an operator at loglevel
error/warn, any more than any successful request is of interest.

This is just log pollution. There is no action for the operator to take.

Re: APLOGNO in 2.2 backports

[William A Rowe Jr]

On Thu, Dec 22, 2016 at 9:33 AM, Eric Covener  wrote:

> Should we have something like this in 2.2:
>
> #define APLOGNO(s) ""
>
> So subsequent backports don't need manual merging when the context has
> a message ID in it?
>

IMO, no.

Because if you are applying it as a patch to, say, httpd 2.2.17, the patch
will
still be a broken patch. It would only work from 2.2.32 and onwards (and
after
2.2.32 I'm crossing fingers there isn't any need for onwards.)

APLOGNO in 2.2 backports

[Eric Covener]

Should we have something like this in 2.2:

#define APLOGNO(s) ""

So subsequent backports don't need manual merging when the context has
a message ID in it?

-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1769669 [2/2] - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ docs/manual/ docs/manual/mod/ include/ server/

[Eric Covener]

I think the log severity changes below could use some eyes, especially
in context of 2.2.  Are these lowered because they're redundant?  I
haven't yet looked.

I am tempted to leave the old severities for 2.2 and wait and see if
it's confusing in 2.4 (should not have to enable DEBUG to see the
cause of a 400 error)



> @@ -937,7 +1010,7 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>
>  if (last_field == NULL) {
>  r->status = HTTP_BAD_REQUEST;
> -ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(03442)
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(03442)
>"Line folding encountered before first"
>" header line");
>  return;
> @@ -945,7 +1018,7 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>
>  if (field[1] == '\0') {
>  r->status = HTTP_BAD_REQUEST;
> -ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(03443)
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(03443)
>"Empty folded line encountered");
>  return;
>  }
> @@ -991,9 +1064,7 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>  }
>  memcpy(last_field + last_len, field, len +1); /* +1 for nul */
>  /* Replace obs-fold w/ SP per RFC 7230 3.2.4 */
> -if (strict || strictspaces) {
> -last_field[last_len] = ' ';
> -}
> +last_field[last_len] = ' ';
>  last_len += len;
>
>  /* We've appended this obs-fold line to last_len, proceed to
> @@ -1024,22 +1095,9 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>  {
>  /* Not Strict ('Unsafe' mode), using the legacy parser */
>
> -if (strictspaces && strpbrk(last_field, "\n\v\f\r")) {
> -r->status = HTTP_BAD_REQUEST;
> -ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, 
> APLOGNO(03451)
> -  "Request header presented bad whitespace "
> -  "(disallowed by StrictWhitespace)");
> -return;
> -}
> -else {
> -char *ll = last_field;
> -while ((ll = strpbrk(ll, "\n\v\f\r")))
> -*(ll++) = ' ';
> -}
> -
>  if (!(value = strchr(last_field, ':'))) { /* Find ':' or */
>  r->status = HTTP_BAD_REQUEST;   /* abort bad request */
> -ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, 
> APLOGNO(00564)
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, 
> APLOGNO(00564)
>"Request header field is missing ':' "
>"separator: %.*s", (int)LOG_NAME_MAX_LEN,
>last_field);
> @@ -1051,11 +1109,11 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>
>  *value++ = '\0'; /* NUL-terminate at colon */
>
> -if (strictspaces && strpbrk(last_field, " \t")) {
> +if (strpbrk(last_field, "\t\n\v\f\r ")) {
>  r->status = HTTP_BAD_REQUEST;
> -ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, 
> APLOGNO(03452)
> -  "Request header field name with whitespace 
> "
> -  "(disallowed by StrictWhitespace)");
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, 
> APLOGNO(03452)
> +  "Request header field name presented"
> +  " invalid whitespace");
>  return;
>  }
>
> @@ -1063,15 +1121,17 @@ AP_DECLARE(void) ap_get_mime_headers_cor
>   ++value;/* Skip to start of value   */
>  }
>
> -/* Strip LWS after field-name: */
> -while (tmp_field > last_field
> -   && (*tmp_field == ' ' || *tmp_field == '\t')) {
> -*(tmp_field--) = '\0';
> +if (strpbrk(value, "\n\v\f\r")) {
> +r->status = HTTP_BAD_REQUEST;
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, 
> APLOGNO(03451)
> +  "Request header field value presented"
> +  " bad whitespace");
> +return;
>  }
>
>  if (tmp_field == last_field) {
>  r->status = HTTP_BAD_REQUEST;
> -ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, 
> APLOGNO(03453)
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, 
> APLOGNO(03453)
>"Request header field name was empty");
>  return;
>