Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[William A Rowe Jr]

Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  wrote:
> The issue obviously isn't in the *tagging*. It is the unknown
> aspect of what is expected AFTER the tagging.
>
> I see the tagging as simply a mechanism to force action
> upon the PMC to go down a route which the PMC has not
> decided, from what I can tell, to go down. Maybe I'm wrong.
> But your reply tends to support that interpretation. The tag, per
> se, is not the goal. The goal is to "push" 2.5.0 when, again
> from what I can tell, the PMC has not decided that such
> a push is warranted/needed/desired/whatever.
>
> So if you want to tag, first generate a roadmap, that can be
> shared and discussed with the PMC, and the dev community,
> what that 1st step is intended to lead us to. But let's
> not pretend that such tagging is simply noting a SVN revision.
>
> You may complain that I "single handedly" do Foo and Bar
> and other dictatorial and dangerous stuff, but AFAIK, I've
> never done or proposed anything w/o bringing it up
> to the list 1st (ala PROXY support, mod_wsgi, health
> checks... etc...). Even w/ releases and tags I give
> people more than 24hours notice. Unless, of course,
> your tag was under Lazy Consensus, in which case my
> "veto" was valid, if more "strong" than required. In
> which case, I am sorry for that.

Simplify download distribution directory by dropping sha1 hashes?

[William A Rowe Jr]

HTTPD team,

Since our downloads are to be authenticated by their .asc PGP
signatures, and the hashes simply serve as checksums, is it reasonable
to offer only MD5 and SHA256 at this point?

Anyone without SHA256 (rare, I'd expect) can use MD5 as the simplest
supported checksum. All others should apply the strongest hash
validation.

Thoughts?

Bill

Re: [users@httpd] [ANNOUNCE] Apache HTTP Server 2.4.29 Released

[William A Rowe Jr]

On Mon, Oct 23, 2017 at 11:53 AM, William A Rowe Jr  wrote:
> On Mon, Oct 23, 2017 at 11:45 AM, Jim Jagielski  wrote:
>>  Apache HTTP Server 2.4.29 Released
>>
>> October 23, 2017
>>
>> The Apache Software Foundation and the Apache HTTP Server Project
>> are pleased to announce the release of version 2.4.29 of the Apache
>> HTTP Server ("Apache").  This version of Apache is our latest GA
>> release of the new generation 2.4.x branch of Apache HTTPD and
>> represents fifteen years of innovation by the project, and is
>> recommended over all previous releases. This release of Apache is
>> a security, feature, and bug fix release.
>>
>> We consider this release to be the best version of Apache available, and
>> encourage users of all prior versions to upgrade.
>>
>> Apache HTTP Server 2.4.29 is available for download from:
>>
>>   http://httpd.apache.org/download.cgi
>
> Broken link.

And... back in sync. Thanks for RM'ing!

Re: [users@httpd] [ANNOUNCE] Apache HTTP Server 2.4.29 Released

[William A Rowe Jr]

On Mon, Oct 23, 2017 at 11:45 AM, Jim Jagielski  wrote:
>  Apache HTTP Server 2.4.29 Released
>
> October 23, 2017
>
> The Apache Software Foundation and the Apache HTTP Server Project
> are pleased to announce the release of version 2.4.29 of the Apache
> HTTP Server ("Apache").  This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of innovation by the project, and is
> recommended over all previous releases. This release of Apache is
> a security, feature, and bug fix release.
>
> We consider this release to be the best version of Apache available, and
> encourage users of all prior versions to upgrade.
>
> Apache HTTP Server 2.4.29 is available for download from:
>
>   http://httpd.apache.org/download.cgi

Broken link.

Re: SSLProxy* in section

[William A Rowe Jr]

On Mon, Oct 23, 2017 at 9:54 AM, Stefan Eissing
 wrote:
>
>> Am 23.10.2017 um 16:25 schrieb Yann Ylavic :
>>
>> Hi Stefan,
>>
>> On Mon, Oct 23, 2017 at 2:42 PM, Stefan Eissing
>>  wrote:
>>>
>>> Can you give me a sign if this will arrive soonish or need to be stashed? 
>>> Thanks!
>>
>> I've just updated the backport proposal with the change (r1812193)
>> intended to address compatibility issues raised by Bill (MMN major
>> bump). Looks good to me, Bill?
>>
>> Appart from this, it's still missing votes (2 now since I had to reset
>> Mike's with the change), so reviewers/testers welcome ;)
>
> Quid pro quo. Fair enough. ;-)
>
> I'll await Bill's verdict and review if his thumb is up.

I will review whether ABI is satisfied later this week, don't let that
stop other reviewers from pounding on this change.

I still propose a "State of the /trunk" release candidate this week,
eyeing only an -alpha release to the public, so that all of the
aspects of trunk which now vary from 2.4.x maintenance branch can be
thoroughly inspected by those users who are willing to do so.

So any feature that feels "experimental" or simply untested will
receive some additional eyeballs, and we can start to address any
deficiencies without continuing to disrupt 2.4.x stable in the
process.

I will make this tag later in the week, holler if you see something
you want to and and *will* address over the remainder of this week,
I'm willing to pause 7-10 days to let some things be corrected. I'd
like to make this a monthly exercise, so what is missed can be fixed
for end of Nov. It will be good to have all these enhancements shared
with the community, even if only at -alpha level recognition for a
bit.

Re: [VOTE] Release Apache httpd 2.4.29 as GA

[William A Rowe Jr]

On Thu, Oct 19, 2017 at 4:15 PM, Steffen  wrote:
> I said before: In Apache.dsw is now  project xml  removed, it is not building 
> out of the box with current released apr-util. With coming apr-util 1.6.1 it 
> should be possible to build.
>
> With the expat/xml changes in apr-util and httpd, it is now a hard job for 
> most win users to build.
>
> Going with the “old” Apache.dsw and current apr-util, all looks fine. The 
> 2.4.28 regression mod_proxy loadfactor issue is solved and it works now again.
>
> Formal it is hard to say to go or not, so a +0.

By building out of the box, you mean building expat for you? That
behavior is by design, of course.

Reading your details on the other list, you are having problems with
the envvar, and attempted to build expat into its old location (and
further, are simply going to stay with the old xml.dsp logic not
provided by the expat project?)

Are you launching devenv with the /useenv flag with desired variables
set? It only promises to bring in your environment INCLUDE, LIB,
LIBPATH and PATH variables, so I'm not sure if it is a 100% solution.

It seems you and Gregg want to accomplish three different things,
Gregg thinks the obvious place for expat is under srclib/expat
(actually it unpacks as libexpat, shrug), you want to continue to
expand expat underneath srclib/apr-util/xml/, and I don't care, since
I build it entirely out-of-tree under the unpacked directory name,
configure and install into the target tree, and then set LIB and
INCLUDE as already documented for PCRE.

I'd like to support as many realistic use cases as possible while we
continue to clean up the segregation of httpd from apr[-util|-iconv],
so searching from the apr-util/ tree either xml/expat/lib or
../expat/lib seems reasonable to me.

Doesn't seem this is a regression, unless something that was working
quit working, and the build didn't work before with expat 2.2.4, so
that isn't in question.

Looking for good solutions here to help users accomplish builds in a
variety of ways without overcomplicating our project's long term
maintenance (extra headaches during httpd-2.4 are expected, of
course.) This basic logic should be working, for example;
https://wiki.apache.org/httpd/WindowsTrunkCompilation

Revisiting odd test framework servername behaviors

[William A Rowe Jr]

# Failed test 56 in t/ssl/varlookup.t at line 109 fail #56
# Failed test 58 in t/ssl/varlookup.t at line 109 fail #58

# testing : SSL_SERVER_SAN_DNS_0
# expected: 'localhost'
# received: 'localhost.localdomain'
not ok 56
# testing : SSL_SERVER_SAN_OTHER_dnsSRV_0
# expected: '_https.localhost'
# received: '_https.localhost.localdomain'
not ok 58

This is something I just keep overlooking since I know it is a noop,
a difference between this FC config and a typical config. Wondering
if there isn't a trivial fix?



Original (untweaked) t/TEST prep stderr indicates;

The Subject's Distinguished Name is as follows
countryName   :PRINTABLE:'US'
stateOrProvinceName   :ASN.1 12:'California'
localityName  :ASN.1 12:'San Francisco'
organizationName  :ASN.1 12:'ASF'
organizationalUnitName:ASN.1 12:'httpd-test/rsa-test-2'
commonName:ASN.1 12:'localhost.localdomain'
emailAddress  :IA5STRING:'test-...@httpd.apache.org'
Certificate is to be certified until Oct 19 13:36:33 2018 GMT (365 days)

Write out database with 1 new entries
Data Base Updated

So the prep defaulted to the detected localhost.localdomain rather
than any arbitrary localhost.



Toggling -servername localhost (explicit)

t/modules/access.t(Wstat: 0 Tests: 408 Failed: 31)
  Failed tests:  4, 20-21, 24, 26, 28, 30, 38, 55, 72, 89
106-107, 123-124, 141, 154, 168, 170, 175
192, 209, 226, 277, 290, 304, 306, 311
328, 345, 362

So however we pick the default to populate the rest of the tests is at
odds with how sslvars chooses the default servername value.

And access.t can't handle an explict servername value, in 31 tests.



Toggling -servername host.domain.net, bouncing through the external
IP address results in several new failures in the test framework;

# Failed test 98 in t/apache/expr.t at line 298 fail #75
t/modules/access.t ..
Failed 95/408 subtests

The test framework hangs at
t/modules/http2.t ...
1..52
# Running under perl version 5.024003 for linux
# Current time local: Thu Oct 19 09:45:20 2017
# Current time GMT:   Thu Oct 19 14:45:20 2017
# Using Test.pm version 1.28_01
# Using Apache/Test.pm version 1.41
test case: TC0001, expecting 200: GET http://host.domain.net:8548/

These tests apparently can't handle an external facing port?

Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

[William A Rowe Jr]

On Fri, Oct 13, 2017 at 8:25 AM, Jim Jagielski  wrote:
> Why lump 2.5.0 into all this?
>
> There is no rational reason to force connect 2.4.29 and 2.5.0
>
> Tag 2.4.29 and leave 2.5.0 alone until people discuss it. Until then
> I will veto any foolishness about 2.5.0-whatever.

Good work, you helped established a foundation with two simple
premises, that no code changes can happen without a group
consensus, while no individual can ever block a release, that vote
is not subject to veto; simple majority.

It's only taken you 18 years to single-handedly undo that? Surely
you know there is no such thing as "Your Esteemed" veto. That
was actually the basis for my -0 on 2.4.28, I determined it was an
unwise release (little did we know), but left it at that... any -1 was
going to have no effect whatsoever unless the RM agreed it was
an unwise tag.

2.5.0-[alpha|beta] serves a number of very useful purposes;

  * Is trunk buildable by most? Is it stable? Is it a broken playground
of cruft that is not releasable?

  * By my count, four rather twisted backports are proposed to 2.4.x
none of which have seen any testing whatsoever. Bold suggestion
that these should be pushed on users in the current "maintenance"
branch that users are relying on. An alpha/beta of these features
pushes them to the forefront and may win huge acceptance or
specific objections.

  * Several major Linux distributions are approaching a glide path
towards 2018 final decisions on httpd reversioning; Ubuntu LTS
and RHEL 9 are likely to be locked in by year end for the next
quarter decade. Our lack of momentum spells zero chance to
move toward fixes of longstanding deficiencies.

  * Big news splash on major ssl enhancements that are unreleased.
In theory, the suggestion to alpha the code would have collided
with a news release on the subject in a good way (not withstanding
the late review of your specific issue and appreciation that it was
a much broader issue with invalid C grammar AC tests.)

  * What needs to come next? What third party modules are already
broken? What changes are third party developers clamoring for?
Oh, and we don't ship snapshots, by definition. So, no alpha/beta
cycle results in a lose lose proposition for our consumers.

But with your dismissive attitude, we might as well presume, since
you are rewriting the project and foundation ruleset, that in your
esteemed wisdom, httpd will no longer evolve, so any suggestion
that httpd could be better than it is today is lost on this mailing list
under your esteemed supervision and new rulemaking.

Please reconsider my rational for submitting this suggestion, and
rethink your basis for opposing it.

Cheers,

Bill

Re: svn commit: r1812393 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/http2/ modules/http2/config2.m4

[William A Rowe Jr]

On Wed, Oct 18, 2017 at 12:36 AM, Marion & Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

> Hi,
>
> just for my own curiosity: why do we prefer 32 bits libs?
>

It is not a value judgement, we simply consume lib/pkginfo before
lib64/pkginfo in this patch. We didn't even look at lib64/pkginfo
before, so this is not a regression.

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

Seems Jim is +0 to back out and I'm +0 to keep. First
strong opinion wins so we can get to tagging :)

Absolute consensus on informing our apr, and httpd
builders what not to pass as CFLAGS, and why.


On Oct 16, 2017 13:58, "William A Rowe Jr"  wrote:

> If the patch has merit on it's own, without being generalized, then I'm
> fine
> with tagging 1.6.1 with the OS/X specific backport included.
>
> Note that the proposed httpd fix is still uneasy about the trunk flavor;
> https://ci.apache.org/builders/httpd-trunk/builds/1202
>
>
>
> On Mon, Oct 16, 2017 at 1:11 PM, Jim Jagielski  wrote:
> > The APR fix just handles macOS w/ Xcode9 or clang 5.0.0.
> > -Werror can be set "externally" and whether or not we should
> > actually die is debatable. But considering that AC_CHECK_LIB
> > will never use function prototypes, the long term solution may be
> > to simply never use that.
> >
> > I'm +0 on removing the check for APRs but we need to
> > document this behavior someplace since it can easily cause
> > unrepeatable builds.
>

Re: buildbot failure in on httpd-trunk

[William A Rowe Jr]

Rainer,

https://ci.apache.org/builders/httpd-trunk/builds/1203

would you please re-kick this build from a clean svn checkout? I think we have
various mistakes in our exports.c preprocessor that become tangled in any
rebuild scenario.


On Mon, Oct 16, 2017 at 8:30 AM, Rainer Jung  wrote:
> Am 16.10.2017 um 11:23 schrieb build...@apache.org:
>>
>> The Buildbot has detected a new failure on builder httpd-trunk while
>> building . Full details are available at:
>>  https://ci.apache.org/builders/httpd-trunk/builds/1199
>>
>> Buildbot URL: https://ci.apache.org/
>>
>> Buildslave for this Build: bb_slave6_ubuntu
>>
>> Build Reason: The AnyBranchScheduler scheduler named
>> 'httpd-trunk-on-commit' triggered this build
>> Build Source Stamp: [branch httpd/httpd/trunk] 1812263
>> Blamelist: rjung
>>
>> BUILD FAILED: failed compile
>
>
> The failure is
>
> In file included from
> /home/buildslave/slave/httpd-trunk/build/include/ap_config.h:184:0,
>  from
> /home/buildslave/slave/httpd-trunk/build/include/httpd.h:44,
>  from util_expr_private.h:20,
>  from util_expr_parse.y:32:
> /home/buildslave/slave/httpd-trunk/build/include/ap_config_auto.h:357:16:
> error: two or more data types in declaration specifiers
>  #define rlim_t int
> ^
> /home/buildslave/slave/httpd-trunk/build/build/rules.mk:207: recipe for
> target 'util_expr_parse.lo' failed
>
> which showed up, because now we actually run maintainer mode with -Werror.
>
> Does anybody know hot e can look at the contantes of
> server/util_expr_parse.c in the buildbot build dir?
>
> Regards,
>
> Rainer
>

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

If the patch has merit on it's own, without being generalized, then I'm fine
with tagging 1.6.1 with the OS/X specific backport included.

Note that the proposed httpd fix is still uneasy about the trunk flavor;
https://ci.apache.org/builders/httpd-trunk/builds/1202



On Mon, Oct 16, 2017 at 1:11 PM, Jim Jagielski  wrote:
> The APR fix just handles macOS w/ Xcode9 or clang 5.0.0.
> -Werror can be set "externally" and whether or not we should
> actually die is debatable. But considering that AC_CHECK_LIB
> will never use function prototypes, the long term solution may be
> to simply never use that.
>
> I'm +0 on removing the check for APRs but we need to
> document this behavior someplace since it can easily cause
> unrepeatable builds.

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

I raised the question of whether the OS/X changes introduced and backported
in APR are still necessary or desired, or if they should be backed out, and
whether this patch, munged for APR_ macros, is needed for apr 1.6.3 tag?

Yann suggests;

On Oct 16, 2017 11:31, "Yann Ylavic"  wrote:

I didn't look at the APR issue still, same one?
At first glance, APR_ADD_GCC_CFLAG doesn't exist, neither does
--maintainer-mode try to set -Werror.
Or am I missing something?

Also, do we want this for APR-1.6 and 1.7? IIRC for instance our use
of readdir[_r]() might trigger warnings with latest linuxes, or was
this addressed?



On Oct 16, 2017 11:19,  wrote:

Author: ylavic
Date: Mon Oct 16 16:19:46 2017
New Revision: 1812303

URL: http://svn.apache.org/viewvc?rev=1812303&view=rev
Log:
Propose finalized alternative.

Modified:
httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
STATUS?rev=1812303&r1=1812302&r2=1812303&view=diff

==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Oct 16 16:19:46 2017
@@ -214,6 +214,19 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   in CTR flow, adding my +1 to note that the patch looks sane.]
  rjung: I think we need this also for GCC, not only recent clang.
 See the dev list discusion about using NOTEST_CFLAGS.
+ ylavic: Consider (and test ;) proposal below instead?
+
+  *) configure.in: Fix maintainer mode with GCC/Clang.
+ Setting -Wstrict-prototypes in combination with -Werror leads to
compiler
+ errors during configure checks (autoconf generates incomplete
prototypes).
+ As suggested by Joe, add --maintainer/debugger-mode's CFLAGS in
+ NOTEST_CFLAGS to avoid interractions with autoconf's AC_LANG_PROGRAM.
+ APACHE_ADD_GCC_CFLAG now also forces -Wno-strict-prototypes for
-Werror
+ to work despite AC_LANG_PROGRAM generating this warning by itself.
+ trunk patch: http://svn.apache.org/r1812263
+  http://svn.apache.org/r1812301
+ 2.4.x patch: svn merge -c 1812263,1812301 ^/httpd/httpd/trunk .
+ +1: ylavic


 PATCHES/ISSUES THAT ARE BEING WORKED

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

Your analysis matches mine, but we still have the open concern of your VS
import quirks around the expat library name. Ideas?



On Oct 15, 2017 03:20, "Steffen"  wrote:

> In Apache.dsw is now  project xml  removed, it is not building out of the
> box with current released apr-util.
>
> With coming apr-util 1.6.1 it should be fine.
>
> On Friday 13/10/2017 at 15:20, William A Rowe Jr wrote:
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
>
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
>
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.
>
>
>
>

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

I've been watching the maintainer mode deliberations on dev@apr with great
interest. I'm also keenly aware of Steffen's concerns, especially since
dropping pcre didn't cause nearly this much trouble.

If we are all on the same page, I'll continue to work through the expat
headache on Monday and others hopefully are close to replacing your OS/X
solve with a more comprehensive solution, even if that means dropping the
I'll considered -Werror patch regression.

I think we all want a regression free and all-platform release finally. If
you want to be the RM, that's great!

Would anyone who is actively reviewing please chime in when you see your
concerns solved, whether these are related to maintainer mode or Win32?

TIA, Jim, and testers.



On Oct 14, 2017 08:41, "Jim Jagielski"  wrote:

> OtherBill, I see that 2.4.29 wasn't tagged. Are you still planning on
> doing so? I can T&R on Monday if you like.
>

Re: svn commit: r1812217 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

Reading this commentary, we agree that is an enhancement.

On Oct 15, 2017 06:32,  wrote:

> Author: rjung
> Date: Sun Oct 15 11:31:58 2017
> New Revision: 1812217
>
> URL: http://svn.apache.org/viewvc?rev=1812217&view=rev
> Log:
> Vote, comment.
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> STATUS?rev=1812217&r1=1812216&r2=1812217&view=diff
> 
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Sun Oct 15 11:31:58 2017
> @@ -214,9 +214,24 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>   trunk patch: http://svn.apache.org/r1810448
>http://svn.apache.org/r1810998
>   2.4.x patch: svn merge -c 1810448,1810998 ^/httpd/httpd/trunk .
> - +1: jim, wrowe
> + +1: jim, wrowe, rjung
>   [This seems to fit into the mold of per-platform quirks which we
> process
>in CTR flow, adding my +1 to note that the patch looks sane.]
> + rjung: The following two comments are not meant to block applying
> that change.
> +- A possible enhancement would be to detect the problem, e.g.
> +using AC_CHECK_LIB for a test that should always succeed and
> +if it fails, try again with "-Wno-error=strict-prototypes".
> +- Another more far reaching enhancement would be to add
> +"-Wno-error=strict-prototypes" only during configure but not
> +later when we do the actual build in order to still detect
> missing
> +prototypes then. Since configure does not seem to have the
> +concept of settings only applied during configure run, we
> would
> +need to remember "-Wno-error=strict-prototypes" as a flag we
> just
> +added to make configure work. Then, right before configure
> +generates output files, we would strip any such flag from
> CFLAGS
> +to generate the correct build time CFLAGS.
> +Unfortunately things might get trickier when building apr/apu
> +in combination with httpd.
>
>
>  PATCHES/ISSUES THAT ARE BEING WORKED
>
>
>

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

[William A Rowe Jr]

Thank you for this summary!

On Oct 13, 2017 10:51, "Jim Jagielski"  wrote:

> Let's recall what is really happening...
>
> In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
> This means that functions which lack strict prototypes will "fail".
>
> Now note that AC_CHECK_LIB does not worry about generating
> function calls w/ prototypes, so, for example, when checking
> for luaL_newstate, it will fail *even if the function exists*!
> In fact, this is how I 1st observed the issue: mod_lua was
> no longer being included.
>
> The long and short is that under maintainer mode, we cannot
> expect AC_CHECK_LIB to being correct any longer, because
> the combination of -Werror and -Wstrict-prototypes means
> that any and all functions looked for/checked for using
> AC_CHECK_LIB will NOT be found, due to warnings which are
> now fatal errors during configure time, even if those
> functions DO exist.
>
> PS: CCing dev@apr since APR also uses AC_CHECK_LIB
>

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

On Oct 13, 2017 08:41, "Stefan Eissing" 
wrote:



> Am 13.10.2017 um 15:19 schrieb William A Rowe Jr :
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?

Not any more than in previous releases, I think.

> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.

I build in maintainer mode all the time and use Xcode9 since I
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.


I suspect it works because you first configured APR in maintainer mode, and
httpd inherits cpp flags?

Jim's proposal fixes httpd configured in maintainer mode when a
conventional APR is present, IIUC.

Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

[William A Rowe Jr]

Is anyone seeing an issue of concern about stability on 2.4.x branch?

Has anyone else looked at Jim's proposed fixes for xcode 9 building
under maintainer mode? A couple-line quick fix to configure.in, that
anyone on OS/X should be able to validate in minutes. The same fix
is already present on APR's branches, which I will tag as well.

I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
period, so that the many proposed enhancements can be examined
by alpha testers and our quick adopters of 2.4.28 can be back on track
by early next week. That should simplify getting some of the more
complex patches backported as necessary, or move us forward
in any case.

Re: svn commit: r1808855 [2/2] - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/ docs/manual/mod/mod_proxy.xml modules/http2/ modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.

[William A Rowe Jr]

As with my comments to Jim on OS/X compatibility, is a new vote for a
previously approved commit even necessary? Unless this commit was not
profered for the backport wasn't originally offered, it seems you can
simply commit to right the backport submitted.


On Oct 12, 2017 14:30, "Yann Ylavic"  wrote:

> On Thu, Oct 12, 2017 at 9:18 PM, Yann Ylavic  wrote:
> > On Thu, Oct 12, 2017 at 7:42 PM, William A Rowe Jr 
> wrote:
> >> On Sep 19, 2017 05:17,  wrote:
> >>
> >>
> >> Modified: httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c
> >> URL:
> >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> modules/proxy/mod_proxy.c?rev=1808855&r1=1808854&r2=1808855&view=diff
> >> 
> ==
> >> --- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c (original)
> >> +++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c Tue Sep 19
> 10:17:40
> >> 2017
> >> @@ -103,7 +103,8 @@ static const char *set_worker_param(apr_
> >>  /* Normalized load factor. Used with BalancerMember,
> >>   * it is a number between 1 and 100.
> >>   */
> >> -ival = atoi(val);
> >> +double fval = atof(val);
> >> +ival = fval * 100.0;
> >>  if (ival < 1 || ival > 100)
> >>  return "LoadFactor must be a number between 1..100";
> >>  worker->s->lbfactor = ival;
> >>
> >>
> >> As this patch was obviously never tested by a single reviewer, my
> >> inclination is to revert this non-feature regression, in order to tag a
> >> 2.4.29 tomorrow a.m., Windows and OS/X 10.13 ready with the many small
> fixes
> >> already committed. Then, let this feature be reintroduced when working,
> with
> >> some testing, along with many other enhancements proposed right now but
> all
> >> potentially disruptive, as a 2.4.30 to follow soon after a .29 stability
> >> release.
> >>
> >> Thoughts?
> >
> > Or apply the same thing as r1805206 for the balancer_manager case
> > (which I tested...).
> > Looks like a serious regression which shouldn't skip a release IMHO,
> > can't 2.4.29 wait a bit (if ever, such small fix could be voted quite
> > quickly)?
>
> Hmm, actually this backport was missing r1805195, I noticed for
> r1805190 but not this one...
>

Re: svn commit: r1808855 [2/2] - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/ docs/manual/mod/mod_proxy.xml modules/http2/ modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.

[William A Rowe Jr]

On Thu, Oct 12, 2017 at 2:30 PM, Yann Ylavic  wrote:

> On Thu, Oct 12, 2017 at 9:18 PM, Yann Ylavic  wrote:
> > On Thu, Oct 12, 2017 at 7:42 PM, William A Rowe Jr 
> wrote:
> >> On Sep 19, 2017 05:17,  wrote:
> >>
> >>
> >> Modified: httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c
> >> URL:
> >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> modules/proxy/mod_proxy.c?rev=1808855&r1=1808854&r2=1808855&view=diff
> >> 
> ==
> >> --- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c (original)
> >> +++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c Tue Sep 19
> 10:17:40
> >> 2017
> >> @@ -103,7 +103,8 @@ static const char *set_worker_param(apr_
> >>  /* Normalized load factor. Used with BalancerMember,
> >>   * it is a number between 1 and 100.
> >>   */
> >> -ival = atoi(val);
> >> +double fval = atof(val);
> >> +ival = fval * 100.0;
> >>  if (ival < 1 || ival > 100)
> >>  return "LoadFactor must be a number between 1..100";
> >>  worker->s->lbfactor = ival;
> >>
> >>
> >> As this patch was obviously never tested by a single reviewer, my
> >> inclination is to revert this non-feature regression, in order to tag a
> >> 2.4.29 tomorrow a.m., Windows and OS/X 10.13 ready with the many small
> fixes
> >> already committed. Then, let this feature be reintroduced when working,
> with
> >> some testing, along with many other enhancements proposed right now but
> all
> >> potentially disruptive, as a 2.4.30 to follow soon after a .29 stability
> >> release.
> >>
> >> Thoughts?
> >
> > Or apply the same thing as r1805206 for the balancer_manager case
> > (which I tested...).
> > Looks like a serious regression which shouldn't skip a release IMHO,
> > can't 2.4.29 wait a bit (if ever, such small fix could be voted quite
> > quickly)?
>
> Hmm, actually this backport was missing r1805195, I noticed for
> r1805190 but not this one...
>

Sigh... this is why I suggested rolling it away to get one good release out.
Then integrate. Thank you for pointing out the fix (is) on trunk/.

Since folks are provisioning and breaking their 2.4.27 servers as we are
chatting back and forth, it seems like sharing a 2.4.29 with them sooner
rather than later would be helpful. That's why I propose to tag tomorrow,
and kick off next week with a stable release.

Your effort to gather a vote on the missing patch by morning, that's fine
by me too. Simply expect we should offer something without regressions.

If anyone is building on the new OS/X, please pause to upvote Jim's
proposed maintainer-mode fix under the SHOWSTOPPERS section.
I believe he can simply commit that to 2.4.x as an OS-specific CTR
change. But since I can't validate except by observation, I'm not feeling
right about applying the change myself absent 3 votes. It would be good
to help both Windows and OS/X builders this cycle.

Re: svn commit: r1808855 [2/2] - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/ docs/manual/mod/mod_proxy.xml modules/http2/ modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.

[William A Rowe Jr]

On Sep 19, 2017 05:17,  wrote:


Modified: httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
modules/proxy/mod_proxy.c?rev=1808855&r1=1808854&r2=1808855&view=diff

==
--- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy.c Tue Sep 19
10:17:40 2017
@@ -103,7 +103,8 @@ static const char *set_worker_param(apr_
 /* Normalized load factor. Used with BalancerMember,
  * it is a number between 1 and 100.
  */
-ival = atoi(val);
+double fval = atof(val);
+ival = fval * 100.0;
 if (ival < 1 || ival > 100)
 return "LoadFactor must be a number between 1..100";
 worker->s->lbfactor = ival;


As this patch was obviously never tested by a single reviewer, my
inclination is to revert this non-feature regression, in order to tag a
2.4.29 tomorrow a.m., Windows and OS/X 10.13 ready with the many small
fixes already committed. Then, let this feature be reintroduced when
working, with some testing, along with many other enhancements proposed
right now but all potentially disruptive, as a 2.4.30 to follow soon after
a .29 stability release.

Thoughts?

Re: svn commit: r1740928 - in /httpd/httpd/trunk: ./ include/ modules/http2/ modules/proxy/ modules/ssl/ server/

[William A Rowe Jr]

I will review again tomorrow.

My jump-around idea was to check against all of the bits in not dir loc
file, and if the module's MMN minor is too early, treat the 
section as if that bit is set.



On Oct 11, 2017 16:13, "Yann Ylavic"  wrote:

On Wed, Oct 11, 2017 at 11:02 PM, Yann Ylavic  wrote:
> On Wed, Oct 11, 2017 at 10:49 PM, Yann Ylavic 
wrote:
>> On Wed, Oct 11, 2017 at 10:38 PM, Yann Ylavic 
wrote:
>>>
>>> Thus, how about if there, for 2.4.x only (i.e. backport patch), we'd
>>> instead check for:
 +|| (((forbidden & NOT_IN_PROXY)
 + || (forbidden & NOT_IN_DIR_LOC_FILE) ==
NOT_IN_DIR_LOC_FILE
 + || (forbidden & GLOBAL_ONLY) == GLOBAL_ONLY)
 +&& ((found = ...)
 +|| ...)))
>>> ?
>>
>> Looks like there are other usages of NOT_IN_DIR_LOC_FILE we should
>> hack in ap_check_cmd_context() too, but you probably see the idea...
>
> Actually, I think the correct fix, even for 2.5/trunk, is something
> for the attached patch.
> WDYT?

Sorry, spoke^R patched too soon, this v2 is more correct I guess.

Re: svn commit: r1740928 - in /httpd/httpd/trunk: ./ include/ modules/http2/ modules/proxy/ modules/ssl/ server/

[William A Rowe Jr]

On Mon, Apr 25, 2016 at 7:04 PM,  wrote:

> Author: ylavic
> Date: Tue Apr 26 00:04:57 2016
> New Revision: 1740928
>
> URL: http://svn.apache.org/viewvc?rev=1740928&view=rev
> Log:
> mod_proxy, mod_ssl: Handle SSLProxy* directives in  sections,
> allowing different TLS configurations per backend.
>
>
> Modified: httpd/httpd/trunk/CHANGES
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=
> 1740928&r1=1740927&r2=1740928&view=diff
> 
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Apr 26 00:04:57 2016
> @@ -1,6 +1,9 @@
>   -*- coding:
> utf-8 -*-
>  Changes with Apache 2.5.0
>
> +  *) mod_proxy, mod_ssl: Handle SSLProxy* directives in  sections,
> + allowing different TLS configurations per backend.  [Yann Ylavic]
> +
>*) mod_http2: eliminating h2_io instances for streams, reducing memory
>   pools and footprint. [Stefan Eissing]
>
>
> Modified: httpd/httpd/trunk/include/http_config.h
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/include/
> http_config.h?rev=1740928&r1=1740927&r2=1740928&view=diff
> 
> ==
> --- httpd/httpd/trunk/include/http_config.h (original)
> +++ httpd/httpd/trunk/include/http_config.h Tue Apr 26 00:04:57 2016
> @@ -249,6 +249,8 @@ struct command_struct {
>  #define NONFATAL_UNKNOWN 1024/* Unrecognised directive */
>  #define NONFATAL_ALL (NONFATAL_OVERRIDE|NONFATAL_UNKNOWN)
>
> +#define PROXY_CONF 2048  /**< *.conf inside  only */
> +
>  /** this directive can be placed anywhere */
>  #define OR_ALL (OR_LIMIT|OR_OPTIONS|OR_FILEINFO|OR_AUTHCFG|OR_INDEXES)
>
> @@ -923,9 +925,10 @@ AP_DECLARE(const char *) ap_check_cmd_co
>  #define  NOT_IN_LOCATION0x08 /**< Forbidden in  */
>  #define  NOT_IN_FILES   0x10 /**< Forbidden in  or
> */
>  #define  NOT_IN_HTACCESS0x20 /**< Forbidden in .htaccess files */
> -/** Forbidden in //<
> If>*/
> -#define  NOT_IN_DIR_LOC_FILE(NOT_IN_DIRECTORY|NOT_IN_
> LOCATION|NOT_IN_FILES)
> -/** Forbidden in ///<
> Location>// */
> +#define  NOT_IN_PROXY   0x40 /**< Forbidden in  */
> +/** Forbidden in //<
> If>*/
> +#define  NOT_IN_DIR_LOC_FILE(NOT_IN_DIRECTORY|NOT_IN_
> LOCATION|NOT_IN_FILES|NOT_IN_PROXY)
> +/** Forbidden in ///<
> Location>//*/
>  #define  GLOBAL_ONLY(NOT_IN_VIRTUALHOST|NOT_IN_
> LIMIT|NOT_IN_DIR_LOC_FILE)
>
>  /** @} */
>

Reviewing this in much more depth yesterday ... this doesn't seem
to be a minor MMN bump, so would not be backportable without some
extra heavy lifting on 2.4 interop.

A module previously compiled against 2.4 would not carry the newly
correct definition of NOT_IN_DIR_LOC_FILE because all previously
compiled modules are missing the 0x40 bit, right?

That would be the definition of an MMN major bump, previously
compiled modules require recompilation.

Re: svn commit: r1810012 - in /httpd/httpd/branches/2.4.x: libhttpd.dsp libhttpd.mak

[William A Rowe Jr]

On Tue, Oct 10, 2017 at 4:04 AM, Ivan Zhakov  wrote:

> On 28 September 2017 at 20:17,  wrote:
> >
> > Author: wrowe
> > Date: Thu Sep 28 17:17:42 2017
> > New Revision: 1810012
> >
> > URL: http://svn.apache.org/viewvc?rev=1810012&view=rev
> > Log:
> > Duplicate mod_watchdog.h to include/
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/libhttpd.dsp
> > httpd/httpd/branches/2.4.x/libhttpd.mak
> >
>
> [...]
>
> > Modified: httpd/httpd/branches/2.4.x/libhttpd.mak
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> libhttpd.mak?rev=1810012&r1=1810011&r2=1810012&view=diff
> > 
> ==
> > --- httpd/httpd/branches/2.4.x/libhttpd.mak (original)
> > +++ httpd/httpd/branches/2.4.x/libhttpd.mak Thu Sep 28 17:17:42 2017
> > @@ -233,11 +233,11 @@ OutDir=.\Debug
> >
> >  !IF "$(RECURSE)" == "0"
> >
> > -ALL : ".\server\test_char.h" ".\include\mod_so.h"
> ".\include\mod_proxy.h" ".\include\mod_include.h" ".\include\mod_dav.h"
> ".\include\mod_cgi.h" ".\include\ap_config_layout.h"
> "$(OUTDIR)\libhttpd.dll" "$(DS_POSTBUILD_DEP)"
> > +ALL : ".\server\test_char.h" ".\include\mod_watchdog.h"
> ".\include\mod_so.h" ".\include\mod_proxy.h" ".\include\mod_include.h"
> ".\include\mod_dav.h" ".\include\mod_cgi.h" ".\include\ap_config_layout.h"
> "$(OUTDIR)\libhttpd.dll" "$(DS_POSTBUILD_DEP)"
> >
> >  !ELSE
> >
> > -ALL : "gen_test_char - Win32 Debug" "libaprutil - Win32 Debug"
> "libapriconv - Win32 Debug" "libapr - Win32 Debug" ".\server\test_char.h"
> ".\include\mod_so.h" ".\include\mod_proxy.h" ".\include\mod_include.h"
> ".\include\mod_dav.h" ".\include\mod_cgi.h" ".\include\ap_config_layout.h"
> "$(OUTDIR)\libhttpd.dll" "$(DS_POSTBUILD_DEP)"
> > +ALL : "gen_test_char - Win32 Debug" "libaprutil - Win32 Debug"
> "libapriconv - Win32 Debug" "libapr - Win32 Debug" ".\server\test_char.h"
> ".\include\mod_watchdog.h" ".\include\mod_so.h" ".\include\mod_proxy.h"
> ".\include\mod_include.h" ".\include\mod_dav.h" ".\include\mod_cgi.h"
> ".\include\ap_config_layout.h" "$(OUTDIR)\libhttpd.dll"
> "$(DS_POSTBUILD_DEP)"
> >
> >  !ENDIF
>
> That same change should be applied for Release configuration. See
> attached patch.


Committed, thanks!

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.28 as GA

[William A Rowe Jr]

Thanks.

Now forwarded to users@. Hopefully anyone on dev@ read your vote results
post.


On Oct 8, 2017 10:31, "Reindl Harald"  wrote:

>
>
> Am 08.10.2017 um 15:22 schrieb Jim Jagielski:
>
>> Hrm... looks like it was already announced? At least the
>> website sez it was, and it looks like an Email was
>> sent to announce@a.o but I'm not seeing anything on
>> the httpd lists
>>
>
>  Weitergeleitete Nachricht 
> Betreff:[Announcement] Apache HTTP Server 2.4.28 Released
> Datum:  Thu, 5 Oct 2017 13:49:10 -0500
> Von:William A Rowe Jr 
> An: annou...@httpd.apache.org
>
>
>
>   Apache HTTP Server 2.4.28 Released
>
> October 5, 2017
>
> The Apache Software Foundation and the Apache HTTP Server Project
> are pleased to announce the release of version 2.4.28 of the Apache
> HTTP Server ("Apache").  This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of innovation by the project, and is
> recommended over all previous releases. This release of Apache is
> a security, feature, and bug fix release.
>
>

Re: httpd memory consumption

[William A Rowe Jr]

Have you tried bisecting the config directives to see which is triggering
the memory abuse?

Sounds like the module might not be async-ready, but should httpd really be
doing many thread swaps before the listener thread is tripped?

Does one of your modules load a large table al la Geo IP mapping?

Are you instantiating a scripting runtime, eg PHP or mod_perl?


On Oct 6, 2017 08:04, "Ruediger Pluem"  wrote:

>
>
> On 10/06/2017 10:26 AM, Bert Huijben wrote:
> >
> >
> >> -Original Message-
> >> From: Ruediger Pluem [mailto:rpl...@apache.org]
> >> Sent: vrijdag 6 oktober 2017 09:47
> >> To: Apache HTTP Server Development List 
> >> Subject: httpd memory consumption
> >>
> >> I am currently looking at a core of a httpd 2.4 process using the event
> MPM
> >> that consumed a lot of memory (core dump file size about 1.4 GB).
> >> While taking the core actually no request was processed by this process.
> >> I suspect a memory leak in a 3rd party closed source module.
> >> As I have no view in the 3rd party module I tried to find out the heap
> >> memory usage of httpd and the included modules.
> >>
> >> For this I used the new dump_pool_and_children I added to .gdbinit which
> >> delivers me the memory used by all pools below 'apr_global_pool' and the
> >> amount of memory in the allocator free lists associated to these pools.
> >> This delivered a usage of only a few MB. Of course I am aware that the
> >> process consumes additional memory for stack, static data and text
> >> segments, but this usage should be static.
> >>
> >> Is there any heap usage by httpd that I could have missed?
> >>
> >> - We do not use the unmanaged pools from APR. So I should have caught
> all
> >> pools.
> >> - I do no think that we use allocators that are not used by a pool.
> Hence I
> >> should have caught all allocators and
> >>   its free lists.
> >> - As no request was processed when I captured the core (all worker
> threads
> >> were waiting for work) I doubt that missed
> >>   any or at least large memory consuming buckets.
> >
> > Is APR configured to return memory to the OS? Otherwise you might just
> see all the allocated memory in the free list of the pool allocator(s).
> >
>
> MaxMemFree is set to 2 MB in httpd and the allocator free list's that I
> have checked do not contain much memory (around
> 400 KB in total for all of them).
>
> Regards
>
> Rüdiger
>
>
>

Re: [CLOSED] [VOTE] Release Apache httpd 2.4.28 as GA

[William A Rowe Jr]

Sorry I ran out of cycles to jump on this on the 4th, and didn't see anyone
step up,
so I went ahead and still pushed it out a day late/day early this
afternoon. Hope you
had a worthwhile conference. Please help me double check any errors or
omissions,
I think it was already staged correctly.

You're welcome, for the bounce/"unsubscribe me" traffic save :) The noise
was
actually tolerable, I think our efforts to unsub unroutable accounts is
having some
impact. I just wish we got more feedback by default of whether this was the
@a.o
or @httpd.a.o traffic responses.





On Wed, Oct 4, 2017 at 7:41 AM, Jim Jagielski  wrote:

> Sure. Anyone who wants to announce, please do so!! :)
>
> > On Oct 3, 2017, at 11:47 AM, William A Rowe Jr 
> wrote:
> >
> > On Tue, Oct 3, 2017 at 6:46 AM, Jim Jagielski  wrote:
> >> With more than the required 3 +1 (binding) votes, and no
> >> vetos, I call this vote CLOSED with the result that
> >> the vote passes.
> >>
> >> I will start moving the artifacts for mirror sync and
> >> let's plan on announcing on Friday.
> >
> > Uhm, why?
> >
> > I understand you are travelling for conference, so someone else might
> > need to step up to broadcast the messages. But it only takes 24 hours
> > for all mirrors to catch up... why ask the community to wait till Friday?
> > E.g. jchampion stepped in last time I had to be AFK so we could push
> > out an announcement, I'm certain someone will step up.
> >
> > Footnote - thank you for providing some extra time to hopefully identify
> > the mod_http2 load issues. Once identified and patched, and I'm happy
> > to tag 2.4.29 immediately, if you aren't available, so we can offer fewer
> > stress exceptions in this GA code.
>
>

Re: svn commit: r1808230 - /httpd/httpd/trunk/server/protocol.c

[William A Rowe Jr]

We have been at 2.4.29-dev for a few days now, are you ready to advance
this proposal?



On Fri, Sep 22, 2017 at 1:07 PM, William A Rowe Jr 
wrote:

> On Fri, Sep 22, 2017 at 1:02 PM, Joe Orton  wrote:
> > On Fri, Sep 22, 2017 at 11:39:54AM -0500, William A Rowe Jr wrote:
> >> This defect still appears to exist in 2.4.28-dev, no?
> >>
> >> The rewrite appears to have enjoyed both committer and external testing
> and
> >> the patch looks suitable for backport. It has enjoyed careful
> consideration by
> >> at least four committers.
> >>
> >> Reading https://bz.apache.org/bugzilla/show_bug.cgi?id=61222#c19 Joe
> was
> >> eyeing some additional improvements, but it seems worthwhile to get this
> >> defect fixed in today's T&R.
> >>
> >> Joe, is there a reason to hold on backporting, why this hasn't been
> promoted
> >> to 2.4 STATUS? If you are satisfied, here's my +1 for the backport to
> speed
> >> things up.
> >
> > I don't plan any additional changes, no.  But I'm not very confident we
> > should be throwing a major rewrite of a core filter at 2.4 users with
> > only light testing, especially since there are security fixes pending.
> >
> > I have put this patch in Fedora "Raw Hide" builds to give some extra
> > exposure, and I'd love to hear more testing results here. Given that the
> > bug has sat festering for a long time (maybe since 2.2??) I don't see
> > any urgency, I'd rather get a bit more testing and wait until after .28
> > to ship and avoid regressions.
>
> Cool, add my +1 into your STATUS proposal once 2.4.29-dev rolls around,
> and let's let this live on the maintenance dev branch as long as possible
> to
> pick up any regressions.
>
> Thanks for all your effort on this!
>

Re: .gdbinit changes backports. CTR or RTC?

[William A Rowe Jr]

On Thu, Oct 5, 2017 at 7:28 AM, Eric Covener  wrote:

> On Thu, Oct 5, 2017 at 8:08 AM, Plüm, Rüdiger, Vodafone Group
>  wrote:
> > Is backporting .gdbinit changes to a stable branch CTR or RTC?
>
> I would think CTR for a typical change there is reasonable.
>

+1, this falls into platform-specific-quirks stuff that has long been CTR.

So are Jim's proposed fixes for clang 900, I'd think. Will vote that up
anyways in case of confusion, it looks reasonable on the surface.

Re: svn commit: r1810605 [1/2] - in /httpd/httpd/trunk: include/ server/

[William A Rowe Jr]

On Tue, Oct 3, 2017 at 2:15 AM, Yann Ylavic  wrote:
> On Mon, Oct 2, 2017 at 11:57 PM,   wrote:
>> Author: ylavic
>> Date: Mon Oct  2 21:57:26 2017
>> New Revision: 1810605
>>
>> URL: http://svn.apache.org/viewvc?rev=1810605&view=rev
>> Log:
>> ap_expr: open string expressions to the .
>>
>> Modified:
>> httpd/httpd/trunk/server/util_expr_parse.c
>> httpd/httpd/trunk/server/util_expr_parse.h
>> httpd/httpd/trunk/server/util_expr_scan.l
>
> Note that the above files are auto-generated (if bison/flex is
> installed on the build system).
> Since the .y and .l will change on svn update, the next build will
> generate them again, so if your bison/flex versions differ it will
> produce a local change. Simply revert them, once (for all)...

That's why we commit util_expr_scan.l source in one pass (like .xml
for the docs updates) and generated files in a second, later timestamped
pass. It avoids this tangle.

Re: [CLOSED] Re: [VOTE] Release Apache httpd 2.4.28 as GA

[William A Rowe Jr]

On Tue, Oct 3, 2017 at 6:46 AM, Jim Jagielski  wrote:
> With more than the required 3 +1 (binding) votes, and no
> vetos, I call this vote CLOSED with the result that
> the vote passes.
>
> I will start moving the artifacts for mirror sync and
> let's plan on announcing on Friday.

Uhm, why?

I understand you are travelling for conference, so someone else might
need to step up to broadcast the messages. But it only takes 24 hours
for all mirrors to catch up... why ask the community to wait till Friday?
E.g. jchampion stepped in last time I had to be AFK so we could push
out an announcement, I'm certain someone will step up.

Footnote - thank you for providing some extra time to hopefully identify
the mod_http2 load issues. Once identified and patched, and I'm happy
to tag 2.4.29 immediately, if you aren't available, so we can offer fewer
stress exceptions in this GA code.

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[William A Rowe Jr]

On Thu, Sep 28, 2017 at 7:44 AM, Stefan Eissing
 wrote:
> Update: disregard the man behind the curtain - for now.
>
> I have the strangest effects on my main machine under native macOS 10.12.6, 
> which
> do not happen on my parallels ubuntu image and my laptop with macOS 10.13.0. 
> I tested
> with hyperthreading disabled to exclude the Intel *lake bugs, but it made no 
> difference.
>
> I will upgrade the machine over night to macOS 10.13.0 and check again 
> tomorrow if
> that had any effect.

Interesting. Any further word on this, or more comments that we might
help brainstorm?

> Regardless of all this, I managed to find an edge case assertion fail and 
> made a fix
> on trunk. If we go for 2.4.29, I'll propose that for inclusion. It is not a 
> regression to
> 2.4.27, so no veto from me on 2.4.28.

Thanks for that find and backport. I was wondering if this was related
to the report.

Which machines / os do you observe the load test asserts on?

Re: svn commit: r1810121 - /httpd/httpd/trunk/docs/conf/mime.types

[William A Rowe Jr]

Does this raise concerns for anyone? I'd note than in the case of the x-font
items, we entirely skipped application/font- promotions prior to
font/* registry.

It doesn't seem sane to keep x- tags for posterity, but we might want to mention
the previous application/* types... however we have no predefined format to
mark them deprecated, so I removed them for the time being.



On Fri, Sep 29, 2017 at 10:10 AM,   wrote:
> Author: wrowe
> Date: Fri Sep 29 15:10:29 2017
> New Revision: 1810121
>
> URL: http://svn.apache.org/viewvc?rev=1810121&view=rev
> Log:
> RFC8081, new font/ registry as pointed out by Steffen
>
> Modified:
> httpd/httpd/trunk/docs/conf/mime.types
>
> Modified: httpd/httpd/trunk/docs/conf/mime.types
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?rev=1810121&r1=1810120&r2=1810121&view=diff
> ==
> --- httpd/httpd/trunk/docs/conf/mime.types (original)
> +++ httpd/httpd/trunk/docs/conf/mime.types Fri Sep 29 15:10:29 2017
> @@ -112,9 +112,7 @@ application/exi exi
>  # application/fastsoap
>  # application/fdt+xml
>  # application/fits
> -# application/font-sfnt
>  application/font-tdpfr pfr
> -application/font-woff  woff
>  # application/framework-attributes+xml
>  # application/geo+json
>  application/gml+xmlgml
> @@ -1261,12 +1259,10 @@ application/x-font-bdf  bdf
>  application/x-font-ghostscript gsf
>  # application/x-font-libgrx
>  application/x-font-linux-psf   psf
> -application/x-font-otf otf
>  application/x-font-pcf pcf
>  application/x-font-snf snf
>  # application/x-font-speedo
>  # application/x-font-sunos-news
> -application/x-font-ttf ttf ttc
>  application/x-font-type1   pfa pfb pfm afm
>  # application/x-font-vfont
>  application/x-freearc  arc
> @@ -1534,6 +1530,12 @@ chemical/x-cml   cml
>  chemical/x-csmlcsml
>  # chemical/x-pdb
>  chemical/x-xyz xyz
> +font/collectionttc
> +font/otf   otf
> +# font/sfnt
> +font/ttf   ttf
> +font/woff  woff
> +font/woff2 woff2
>  image/bmp  bmp
>  image/cgm  cgm
>  # image/dicom-rle
>
>

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[William A Rowe Jr]

On Mon, Sep 25, 2017 at 12:11 PM, Steffen  wrote:
> On Windows it does not build out of the box.
>
> Missing modules/core include for mod_watchdog.h in
> mod_proxy_balancer.dsp/mak and libhttp.dsp/mak . Did not checked cmake.

Seems baffling, but it is pretty straightforward in hindsight.

libhttpd is built first before modules/*

libhttpd compiles in mod_so (alongside core, win32, mpm_winnt, and http.)

libhttpd starts by copying mod_so.h to include/, originally the only module,
just as the unix build had long done so when mod_so was enabled.
There was no need to /I modules/core with that header in include/

modules/core/mod_watchdog was added - but built as a loadable module.
The .h was neither copied to include/ nor was /I include/core added.

mod_heartbeat, mod_heartmonitor, mod_proxy_balancer and mod_proxy_hcheck
all include mod_watchdog; it makes more sense to copy this header as well,
rather than modify four projects. I'm a little confused how libhttpd would need
it itself, but that's where include copying should occur for now.

Fixed in r1810012

Re: [VOTE] Release Apache httpd 2.4.28 as GA

[William A Rowe Jr]

The assert() has me concerned, and Steffen's report is problematic. He has
a vote but hasn't cast it. At this moment I'm -0 and would spin a 2.4.29
next week to address these issues, unless you decide to respin before this
release, yourself.

Nothing I've changed today altered the httpd tarball significantly.
Studying Steffen's report next, along with some apparently missing glue for
brotli.

My solution is going to be radical, shove every last d*mned modules/foo
into the /I path includes list so this can't happen again during 2.4, and
hopefully not until 20 year old build logic is discarded. One less thing to
worry about or pre-review when RM's loudly announce an upcoming tag.




On Sep 25, 2017 07:13, "Jim Jagielski"  wrote:

> The pre-release test tarballs for Apache httpd
> version 2.4.28 can be found at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.28 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>

Re: svn commit: r1808230 - /httpd/httpd/trunk/server/protocol.c

[William A Rowe Jr]

On Fri, Sep 22, 2017 at 1:02 PM, Joe Orton  wrote:
> On Fri, Sep 22, 2017 at 11:39:54AM -0500, William A Rowe Jr wrote:
>> This defect still appears to exist in 2.4.28-dev, no?
>>
>> The rewrite appears to have enjoyed both committer and external testing and
>> the patch looks suitable for backport. It has enjoyed careful consideration 
>> by
>> at least four committers.
>>
>> Reading https://bz.apache.org/bugzilla/show_bug.cgi?id=61222#c19 Joe was
>> eyeing some additional improvements, but it seems worthwhile to get this
>> defect fixed in today's T&R.
>>
>> Joe, is there a reason to hold on backporting, why this hasn't been promoted
>> to 2.4 STATUS? If you are satisfied, here's my +1 for the backport to speed
>> things up.
>
> I don't plan any additional changes, no.  But I'm not very confident we
> should be throwing a major rewrite of a core filter at 2.4 users with
> only light testing, especially since there are security fixes pending.
>
> I have put this patch in Fedora "Raw Hide" builds to give some extra
> exposure, and I'd love to hear more testing results here. Given that the
> bug has sat festering for a long time (maybe since 2.2??) I don't see
> any urgency, I'd rather get a bit more testing and wait until after .28
> to ship and avoid regressions.

Cool, add my +1 into your STATUS proposal once 2.4.29-dev rolls around,
and let's let this live on the maintenance dev branch as long as possible to
pick up any regressions.

Thanks for all your effort on this!

Re: Time for 2.4.28 ?

[William A Rowe Jr]

On Fri, Sep 22, 2017 at 7:06 AM, Jim Jagielski  wrote:
> STATUS looks clean.
>
> Hoping to do a T&R this afternoon, eastern, unless I hear
> any objections or concerns re: timing.

svn looks good here. Only one potentially missed item IMO, it could wait
till 2.4.29, but if we hear right back from jorton or rpluem on the readiness
of the patch, I'd love to see us quit consuming extra memory r.e. PR61222,
so the backport has my +1 already. If you look at comments in this ticket,
the review has already happened and everyone seemed mostly satisfied.

Suggesting a parallel apr/-util release over on dev@apr. Thanks for RM'ing!

Re: svn commit: r1808230 - /httpd/httpd/trunk/server/protocol.c

[William A Rowe Jr]

This defect still appears to exist in 2.4.28-dev, no?

The rewrite appears to have enjoyed both committer and external testing and
the patch looks suitable for backport. It has enjoyed careful consideration by
at least four committers.

Reading https://bz.apache.org/bugzilla/show_bug.cgi?id=61222#c19 Joe was
eyeing some additional improvements, but it seems worthwhile to get this
defect fixed in today's T&R.

Joe, is there a reason to hold on backporting, why this hasn't been promoted
to 2.4 STATUS? If you are satisfied, here's my +1 for the backport to speed
things up.



On Wed, Sep 13, 2017 at 5:59 AM,   wrote:
> Author: jorton
> Date: Wed Sep 13 10:59:51 2017
> New Revision: 1808230
>
> URL: http://svn.apache.org/viewvc?rev=1808230&view=rev
> Log:
> * server/protocol.c (ap_content_length_filter): Rewrite the content
>   length filter to avoid arbitrary memory consumption for streaming
>   responses (e.g. large CGI script output).  Ensures C-L is still
>   generated in common cases (static content, small CGI script output),
>   but this DOES change behaviour and some responses will end up
>   chunked rather than C-L computed.
>
> PR: 61222
> Submitted by: jorton, rpluem
>
> Modified:
> httpd/httpd/trunk/server/protocol.c
>
> Modified: httpd/httpd/trunk/server/protocol.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?rev=1808230&r1=1808229&r2=1808230&view=diff
> ==
> --- httpd/httpd/trunk/server/protocol.c (original)
> +++ httpd/httpd/trunk/server/protocol.c Wed Sep 13 10:59:51 2017
> @@ -1708,62 +1708,88 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
>  ctx->tmpbb = apr_brigade_create(r->pool, 
> r->connection->bucket_alloc);
>  }
>
> -/* Loop through this set of buckets to compute their length
> - */
> +/* Loop through the brigade to count the length. To avoid
> + * arbitrary memory consumption with morphing bucket types, this
> + * loop will stop and pass on the brigade when necessary. */
>  e = APR_BRIGADE_FIRST(b);
>  while (e != APR_BRIGADE_SENTINEL(b)) {
> +apr_status_t rv;
> +
>  if (APR_BUCKET_IS_EOS(e)) {
>  eos = 1;
>  break;
>  }
> -if (e->length == (apr_size_t)-1) {
> +/* For a flush bucket, fall through to pass the brigade and
> + * flush now. */
> +else if (APR_BUCKET_IS_FLUSH(e)) {
> +e = APR_BUCKET_NEXT(e);
> +}
> +/* For metadata bucket types other than FLUSH, loop. */
> +else if (APR_BUCKET_IS_METADATA(e)) {
> +e = APR_BUCKET_NEXT(e);
> +continue;
> +}
> +/* For determinate length data buckets, count the length and
> + * continue. */
> +else if (e->length != (apr_size_t)-1) {
> +r->bytes_sent += e->length;
> +e = APR_BUCKET_NEXT(e);
> +continue;
> +}
> +/* For indeterminate length data buckets, perform one read. */
> +else /* e->length == (apr_size_t)-1 */ {
>  apr_size_t len;
>  const char *ignored;
> -apr_status_t rv;
> -
> -/* This is probably a pipe bucket.  Send everything
> - * prior to this, and then read the data for this bucket.
> - */
> +
>  rv = apr_bucket_read(e, &ignored, &len, eblock);
> +if ((rv != APR_SUCCESS) && !APR_STATUS_IS_EAGAIN(rv)) {
> +ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(00574)
> +  "ap_content_length_filter: "
> +  "apr_bucket_read() failed");
> +return rv;
> +}
>  if (rv == APR_SUCCESS) {
> -/* Attempt a nonblocking read next time through */
>  eblock = APR_NONBLOCK_READ;
> +e = APR_BUCKET_NEXT(e);
>  r->bytes_sent += len;
>  }
>  else if (APR_STATUS_IS_EAGAIN(rv)) {
> -/* Output everything prior to this bucket, and then
> - * do a blocking read on the next batch.
> - */
> -if (e != APR_BRIGADE_FIRST(b)) {
> -apr_bucket *flush;
> -apr_brigade_split_ex(b, e, ctx->tmpbb);
> -flush = 
> apr_bucket_flush_create(r->connection->bucket_alloc);
> -
> -APR_BRIGADE_INSERT_TAIL(b, flush);
> -rv = ap_pass_brigade(f->next, b);
> -if (rv != APR_SUCCESS || f->c->aborted) {
> -return rv;
> -}
> -apr_brigade_cleanup(b);
> -APR_BRIGADE_CONCAT(b, ctx->tmpbb);
> -e = APR_BRIGADE_FIRST(b);
> +apr_bucket *flush;
>
> -ctx->data_sent = 1;
> -}
> +/* Next rea

Re: svn commit: r1809192 - /httpd/site/trunk/content/security/vulnerabilities-httpd.xml

[William A Rowe Jr]

What more would we want to say here? Mention that the Allow: header may respond
with corrupted output? It seems other side effects can be present, which is why
I kept this simple.


On Thu, Sep 21, 2017 at 1:33 PM,   wrote:
> Author: wrowe
> Date: Thu Sep 21 18:33:47 2017
> New Revision: 1809192
>
> URL: http://svn.apache.org/viewvc?rev=1809192&view=rev
> Log:
> Record CVE-2017-9798
>
> Modified:
> httpd/site/trunk/content/security/vulnerabilities-httpd.xml
>
> Modified: httpd/site/trunk/content/security/vulnerabilities-httpd.xml
> URL: 
> http://svn.apache.org/viewvc/httpd/site/trunk/content/security/vulnerabilities-httpd.xml?rev=1809192&r1=1809191&r2=1809192&view=diff
> ==
> --- httpd/site/trunk/content/security/vulnerabilities-httpd.xml (original)
> +++ httpd/site/trunk/content/security/vulnerabilities-httpd.xml Thu Sep 21 
> 18:33:47 2017
> @@ -1,4 +1,99 @@
> -
> +
> +
> +
> +
> +low
> +Use-after-free when using  with an unrecognized method 
> in .htaccess ("OptionsBleed")
> +
> +When an unrecognized HTTP Method is given in an 
> +directive in an .htaccess file, and that .htaccess file is processed by the
> +corresponding request, the global methods table is corrupted in the current
> +worker process, resulting in erratic behaviour.
> +This behavior may be avoided by listing all unusual HTTP Methods in a 
> global
> +httpd.conf RegisterHttpMethod directive in httpd release 2.4.25 and 
> later.
> +To permit other .htaccess directives while denying the  
> directive, see the AllowOverrideList directive.
> +Source code patch is at;
> +
> + href="http://www.apache.org/dist/httpd/patches/apply_to_2.4.27/CVE-2017-9798-patch-2.4.patch";
> +>http://www.apache.org/dist/httpd/patches/apply_to_2.4.27/CVE-2017-9798-patch-2.4.patch
> +
> +
> +
> +We would like to thank Hanno Böck for reporting this issue.
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +low
> +Use-after-free when using  with an unrecognized method 
> in .htaccess ("OptionsBleed")
> +
> +When an unrecognized HTTP Method is given in an 
> +directive in an .htaccess file, and that .htaccess file is processed by the
> +corresponding request, the global methods table is corrupted in the current
> +worker process, resulting in erratic behaviour.
> +This behavior may be avoided by listing all unusual HTTP Methods in a 
> global
> +httpd.conf RegisterHttpMethod directive in httpd release 2.2.32 and 
> later.
> +To permit other .htaccess directives while denying the  
> directive, see the AllowOverrideList directive.
> +Source code patch is at;
> +
> + href="http://www.apache.org/dist/httpd/patches/apply_to_2.2.34/CVE-2017-9798-patch-2.4.patch";
> +>http://www.apache.org/dist/httpd/patches/apply_to_2.2.34/CVE-2017-9798-patch-2.2.patch
> +
> +Note 2.2 is end-of-life, no further release with this fix is planned. 
> Users
> +are encouraged to migrate to 2.4.28 or later for this and other fixes.
> +
> +
> +We would like to thank Hanno Böck for reporting this issue.
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>   released="20170711">
>  
>
>

Re: configure option --enable-option-checking warns about things it does know (httpd-2.2.X)

[William A Rowe Jr]

Thanks for the report Michael.

The 2.2.x series is now retired and end-of-life.

The warnings are no-ops... they are inherited to child ./configure bits so
the basic httpd-2.x/configure may holler about options only applicable to
the bundled packages, and the bundled packages may holler about options
only applicable to httpd.

We have unbundled the dependencies from httpd 2.4, apr and apr-util 1.6,
so expat -> pcre -> zlib -> apr -> apr-util -> httpd must be build
independently,
and this side-effect of passing around unrecognized configure flags is moot.

Bill

On Thu, Sep 21, 2017 at 6:55 AM, Michael  wrote:
> Just thought I would mention option-checking in httpd-2.2.X is borked.
>
> Fortunately, it just warns :)
>
> A small subset of the warnings:
>
> configure: WARNING: unrecognized options: --with-z, --enable-layout,
> --with-apr, --with-apr-util, --with-mpm, --enable-ssl, --enable-proxy,
> --enable-mods-shared
>
> Regards,
>
> Michael
>
> p.s. I have not been following the maillist for quite a while - so if this
> is already known, please ignore.
>
>

Understanding OptionsBleed

[William A Rowe Jr]

So as most people have correctly identified, this defect has existed
for an incredibly long time.

But how it is triggered and avoided would help us to correctly study
unexpected behaviors.

OPTIONS * - won't trigger the defect, .htaccess should not be examined.

OPTIONS / - may trigger the defect, because the path is traversed and
one or more .htaccess files may be processed.

In all versions,  of the standard methods do not trigger the
defect. Only  of any unregistered methods in an allowed
.htaccess file will trigger the defect.

In 2.4.23 and prior including all 2.2/2.0, "HEAD" was not registered,
but would not be registered by  HEAD
and HEAD --> HEAD resulting in four methods listed, fixed already in
2.4.27.

In order to avoid the defect with trusted .htaccess authors;

In 2.2.31 and prior (all 2.0) or 2.4.23 and prior we can use an
otherwise no-op https://httpd.apache.org/docs/2.4/mod/core.html#allowoverridelist

The httpd server cannot ever address every possible aspect of
malicious .htaccess authoring, and the project has reiterated this
message multiple times, leading to a vulnerability assessment of 'low'
severity in all cases that weren't disputed as not vulnerabilities
whatsoever;

https://www.cvedetails.com/cve/CVE-2011-3607/
https://www.cvedetails.com/cve/CVE-2011-4415/
https://www.cvedetails.com/cve/CVE-2009-1195/
https://www.cvedetails.com/cve/CVE-2004-2343/
https://www.cvedetails.com/cve/CVE-2004-0747/

Re: mime type woff woff2

[William A Rowe Jr]

Duplicate file type matches will just confuse the hash lookup, I suspect.
Drop the file-types from deprecated mime type entries, include mention the
deprecated types though, for the sake of completeness. There are other
examples of this pattern in mime.types, of types with no file type assigned.



On Sep 18, 2017 03:21, "Steffen"  wrote:

> In conf mime.types we have:
>
> application/font-woff woff
>
> And missing woff2 (have several request to add)
>
> According to IANA https://www.iana.org/assignments/media-types/media-
> types.xhtml#application :
>
> font-woff - *DEPRECATED* in favor of font/woff  application/font-woff
> 
>
>
> According https://www.iana.org/assignments/media-types/
> media-types.xml#font
>
> woff font/wof
> woff2 font/woff2
>
> Do we change/add in mime.types : ?
>
> change application/font-woffwoff   to  font/woff  woff
>
> and add  font/wof2  woff2  ?
>
> Or do we need both : ?
>
> application/font-woffwoff
> application/font-woff2woff2
> font/woff  woff
> font/woff2  woff2
>

Re: svn commit: r1426877 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c server/util.c server/vhost.c

[William A Rowe Jr]

This has been the object of some debate, read Lisa's errata rejection of ID
1081 and 1353...

https://www.rfc-editor.org/errata/rfc1123



On Sep 16, 2017 10:00, "Eric Covener"  wrote:

On Sat, Sep 16, 2017 at 9:48 AM, Yann Ylavic  wrote:
> On Sat, Sep 16, 2017 at 3:37 AM, Eric Covener  wrote:
>> On Sat, Dec 29, 2012 at 8:23 PM,   wrote:
>>>
>>> +/*
>>> + * If strict mode ever becomes the default, this should be folded into
>>> + * fix_hostname_non_v6()
>>> + */
>>> +static apr_status_t strict_hostname_check(request_rec *r, char *host,
>>> +  int logonly)
>>> +{
>>> +char *ch;
>>> +int is_dotted_decimal = 1, leading_zeroes = 0, dots = 0;
>>> +
>>> +for (ch = host; *ch; ch++) {
>>> +if (!apr_isascii(*ch)) {
>>> +goto bad;
>>> +}
>>> +else if (apr_isalpha(*ch) || *ch == '-') {
>>> +is_dotted_decimal = 0;
>>> +}
>>> +else if (ch[0] == '.') {
>>> +dots++;
>>> +if (ch[1] == '0' && apr_isdigit(ch[2]))
>>> +leading_zeroes = 1;
>>> +}
>>> +else if (!apr_isdigit(*ch)) {
>>> +   /* also takes care of multiple Host headers by denying
commas */
>>> +goto bad;
>>> +}
>>> +}
>>> +if (is_dotted_decimal) {
>>> +if (host[0] == '.' || (host[0] == '0' && apr_isdigit(host[1])))
>>> +leading_zeroes = 1;
>>> +if (leading_zeroes || dots != 3) {
>>> +/* RFC 3986 7.4 */
>>> +goto bad;
>>> +}
>>> +}
>>> +else {
>>> +/* The top-level domain must start with a letter (RFC 1123
2.1) */
>>> +while (ch > host && *ch != '.')
>>> +ch--;
>>> +if (ch[0] == '.' && ch[1] != '\0' && !apr_isalpha(ch[1]))
>>> +goto bad;
>>> +}
>>> +return APR_SUCCESS;
>>> +
>>> +bad:
>>> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO()
>>> +  "[strict] Invalid host name '%s'%s%.6s",
>>> +  host, *ch ? ", problem near: " : "", ch);
>>> +if (logonly)
>>> +return APR_SUCCESS;
>>> +return APR_EINVAL;
>>> +}
>>
>> (sorry for the necromancy of this very old commit)
>>
>> Re: the 1123 2.1 reference a dozen lines from the end of the function:
>> RFC 1123 2.1 seems to say the opposite. Just a bug or something over
>> my head?
>>
>>   2.1  Host Names and Numbers
>>
>>   The syntax of a legal Internet host name was specified in RFC-952
>>   [DNS:4].  One aspect of host name syntax is hereby changed: the
>>   restriction on the first character is relaxed to allow either a
>>   letter or a digit.  Host software MUST support this more liberal
>>   syntax.
>
> RFC 1123 2.1 seems to be about the first character of the host, while
> the code checks the first one of the TLD. Are there TLDs starting with
> a digit?

I see, thanks.  The basis in 1123 is a bit later in 2.1 but doesn't
really seem normative:

If a dotted-decimal number can be entered without such
   identifying delimiters, then a full syntactic check must be
   made, because a segment of a host domain name is now allowed
   to begin with a digit and could legally be entirely numeric
   (see Section 6.1.2.4).  However, a valid host name can never
   have the dotted-decimal form #.#.#.#, since at least the
   highest-level component label will be alphabetic.

The 6.1.2.4 reference is likely an error because that is about compression.

It seems like we'd reject "1foo" but accept "1foo.com", but i am not
sure if this warrants an exception or reconsidering the check.

(In the case that had me looking, a high TCP port was used as the
hostname AND port in the Host header so it is clearly someone elses
bug at the core)

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

Re: Flood 0.4 status? (was: flood 0.4 was never signed for?)

[William A Rowe Jr]

I know many of you had busy summers and August holidays... just want
to be sure that nobody who wanted to comment has missed discussion
of retiring the Flood subproject.

If we don't reach any other conclusion or interest, we should wind this down
next week in response to Daniel's concern from the Infra team.

The only remaining question is do we (httpd PMC) archive this, or do we
hand the baton off to the Attic for this legacy source code?




On Wed, Sep 6, 2017 at 12:25 AM, Luca Toscano  wrote:
> Hi William,
>
> As far as I can see the project seems abandoned, so in my opinion unless
> somebody steps up to work on it I'd be in favor of remove it from
> www.a.o/dist/httpd/flood.
>
> Luca
>
>
> 2017-09-01 18:39 GMT+02:00 William A Rowe Jr :
>>
>> What's our position on this? Is it time to declare flood abandoned?
>>
>> Are there any users of this tool who want to contribute to maintaining it?
>>
>> Offhand, I expect it does not support TLS/SNI. Nor HTTP/2.
>>
>> If abandoned, we can simply remove www.a.o/dist/httpd/flood
>> to resolve Daniel's issue. If not abandoned, regenerating the
>> tarball from should result in the same file, which can then be
>> signed.
>>
>> Thoughts?
>>
>>
>>
>> On Sat, Aug 19, 2017 at 12:43 AM, Daniel Gruno 
>> wrote:
>> > Hi folks,
>> >
>> > It appears that flood 0.4 (
>> > https://dist.apache.org/repos/dist/release/httpd/flood/ ) was never
>> > signed by anyone, which should likely be fixed. As this was, AIUI,
>> > released 8 years ago, I cannot in good conscience sign for it myself.
>> >
>> > Either we have someone who was present back then sign for it, or we
>> > should remove the release, pursuant to our release policy.
>> >
>> > With regards,
>> > Daniel.
>
>

Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

[William A Rowe Jr]

On Thu, Sep 14, 2017 at 4:50 AM, Nick Kew  wrote:
> On Wed, 13 Sep 2017 08:29:44 -0500
> William A Rowe Jr  wrote:
>
>> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
>> our HTTP/1.1 server? Do we really want people to configure their
>> server to speak "other"?
>
> Did you mean to say "stop accepting ..."?
>
>> I'm starting to collect https://wiki.apache.org/httpd/Applications
>> based on searching google for instances where users have toggled
>> HttpProtocolOptions Unsafe, in response to specific application
>> behavior.
>
> Perhaps a useful exercise, but could take us in to a bad cycle
> of application workarounds that long-outlive the application
> being fixed.
>
>> From this list, we might decide to allow non-HTTP/1.1 input in
>> specific cases, and perhaps have multiple grades of protocol
>> correctness, as I first proposed.
>
> You mean something like Options or AllowOverride?  Things that looked
> like a good idea at the time but led to all sorts of issues as the
> server evolved!
>
> OK, perhaps that's unduly harsh: this will be less problematic to
> maintain.  Are you enumerating cases?

I'm strictly taking a survey of reported conflicts with the newer
HttpProtocolOptions Strict behaviors.

My goal isn't to work around them, simply find out their prevalence
in order to make a binary decision over dropping all legacy GIGO
behavior (actually, garbage in, as we have generally done a nice job
of normalizing the request to the backend or response to the client,
which is what leads to splitting/injection vectors.)

Tomcat and other servers and proxies are taking serious steps
toward accepting only valid input. 2.next/3.0 won't be here for
some time, leaving lots of chances for authors to fix the defects
in the client or upstream/app server or custom clients.

My question is whether HttpProtocolOptions Unsafe is needed,
beyond the 2.4.x lifespan of our project? Conversely, did Unsafe
still block some inadvisable but tolerable requests or responses?
That's the purpose of the wiki incompatibilities page.

Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

[William A Rowe Jr]

So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
our HTTP/1.1 server? Do we really want people to configure their
server to speak "other"?

I'm starting to collect https://wiki.apache.org/httpd/Applications
based on searching google for instances where users have toggled
HttpProtocolOptions Unsafe, in response to specific application
behavior.

>From this list, we might decide to allow non-HTTP/1.1 input in
specific cases, and perhaps have multiple grades of protocol
correctness, as I first proposed. A trailing space, after the protocol
designation in the request line is one example of a rather
unambiguously safe incompatibility.

Re: svn commit: r1807777 - /httpd/httpd/trunk/modules/md/Makefile.in

[William A Rowe Jr]

On Fri, Sep 8, 2017 at 10:14 AM, Yann Ylavic  wrote:
> Hi Stefan,
>
> On Fri, Sep 8, 2017 at 5:06 PM,   wrote:
>> Author: icing
>> Date: Fri Sep  8 15:06:44 2017
>> New Revision: 180
>>
>> URL: http://svn.apache.org/viewvc?rev=180&view=rev
>> Log:
>> On the trunk:
>>
>> mod_md: added necessary CPPFLAGS for a2md build.
>
> Thanks, it fixed some APR dependencies for me.
>
> Now I'm here:
>
> || *** Warning: Linking the shared library mod_md.la against the non-libtool
> || *** objects  md_acme.o md_acme_acct.o md_acme_authz.o
> md_acme_drive.o md_core.o md_curl.o md_crypt.o md_http.o md_json.o
> md_jws.o md_log.o md_reg.o md_store.o md_store_fs.o md_util.o is not
> portable!
> || /home/yle/bin/ld: error: md_json.o: requires dynamic R_X86_64_PC32
> reloc against 'md_json_destroy' which may overflow at runtime;
> recompile with -fPIC
> || /home/yle/bin/ld: error: md_reg.o: requires dynamic R_X86_64_PC32
> reloc against 'md_reg_find_overlap' which may overflow at runtime;
> recompile with -fPIC
> || /home/yle/bin/ld: error: md_util.o: requires dynamic R_X86_64_PC32
> reloc against 'md_array_str_index' which may overflow at runtime;
> recompile with -fPIC
> || collect2: error: ld returned 1 exit status
>
> Any idea?


Missing CFLAGS or wrong CC invocation.

Re: Listen 443 https

[William A Rowe Jr]

Reminder, this will not work with the current server_rec, we have a 1:1
correspondence to the server port. We would need to stop looking at that
field and track the port entirely on the connection and the server rec
addresses array.

On Fri, Sep 1, 2017 at 10:12 AM, Eric Covener  wrote:
> On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
>  wrote:
>> I get the first feedback from Apache users that want their http: only
hosts to also serve https:. This is nice feedback to improve usability of
mod_md.
>>
>> Ideally, what these people want - and that is purely my interpretation -
is to add a few lines to their config and - voila - https: is available.
And, honestly, why should they not expect that?
>>
>>
>>
>> Example: Duplication/Redirect
>>
>> They have something like:
>> --
>> Listen 80
>> 
>> ServerName xxx.yyy
>> ...
>> 
>> --
>>
>> and want to also make that available on https:
>> --
>> Listen http://*:80
>> Listen https://*:443
>>
>> 
>> ServerName xxx.yyy
>> AlternatePorts 443
>> ...
>> 
>> --
>>
>> or redirect everyone to https:
>> --
>> Listen http://*:80
>> Listen https://*:443
>>
>> 
>> ServerName xxx.yyy
>> RedirectPermanentFrom 80
>> ...
>> 
>
> I am not keen on the syntax because we already permit multiple
> addresses in the VirtualHost tag.
>
> How about e.g.
>
> 

Again, fo

Flood 0.4 status? (was: flood 0.4 was never signed for?)

[William A Rowe Jr]

What's our position on this? Is it time to declare flood abandoned?

Are there any users of this tool who want to contribute to maintaining it?

Offhand, I expect it does not support TLS/SNI. Nor HTTP/2.

If abandoned, we can simply remove www.a.o/dist/httpd/flood
to resolve Daniel's issue. If not abandoned, regenerating the
tarball from should result in the same file, which can then be
signed.

Thoughts?



On Sat, Aug 19, 2017 at 12:43 AM, Daniel Gruno  wrote:
> Hi folks,
>
> It appears that flood 0.4 (
> https://dist.apache.org/repos/dist/release/httpd/flood/ ) was never
> signed by anyone, which should likely be fixed. As this was, AIUI,
> released 8 years ago, I cannot in good conscience sign for it myself.
>
> Either we have someone who was present back then sign for it, or we
> should remove the release, pursuant to our release policy.
>
> With regards,
> Daniel.

Missing make install files?

[William A Rowe Jr]

This slightly overlaps what Jacob has been working on with his
schema for our autobuilds, wrapping up my own work and then
turning to his efforts to see where we have some good synergies
to exchange.

One thing that has stood out, but I never claimed I had much
skill in the unix build schema (now other committers put me to
shame on win32, and I clean up most everyone else's autocrud
messes, odd... eh?) So I left it alone, but this seems silly now...

On Unix, what about LICENSE and NOTICE (perhaps README
and CHANGES in the process?) Is there a reason, after insisting
loudly that the first two must be replicated, that we don't deposit
them somewhere in the build $(TARGET)?

Opening this up for discussion, 1) should we? and 2) where to?

Cheers,

Bill

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald 
wrote:
>
> 
>  ServerName corecms.example.com
>  DocumentRoot "/www/corecms.example.com"
>  

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your certificate file
and your stapling choice from affecting h2 requests on port 80.


Another reason this will not work... Server/VHost config is static. All
such directives are evaluated at config/startup time, global config is
merged to per-vhost config. And that is the state of the host for that
generation of the workers process.  will never be supported for those
directives, it can work only on per-dir config options.

Final reason this won't be adopted as suggested; VirtualHost [:80] is
implicit. I cannot see us ever changing this, it would break most configs.
Maybe a port * feature?

If you want to experiment...

is already recognized.

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald  wrote:
>
> it also would solve the chicken-egg-problem (again, without mod_md) that you
> first need the http-host working for the well-known verfication file and the
> path of the certificate could be easily pre-configured in the way of my
> example, just warn insteda a fatal error on reload when the certfile don't
> exist
> 
>
> 
>  ServerName corecms.example.com
>  DocumentRoot "/www/corecms.example.com"
>  
>   SSLEngine On
>   SSLUseStapling Off
>   SSLCertificateFile "conf/ssl/corecms.pem"
>  
>  
>   php_admin_value open_basedir "/www/corecms.example.com"
>   php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
>  
> 

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your certificate file
and your stapling choice from affecting h2 requests on port 80.

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:19 AM, Stefan Eissing
 wrote:
>
>> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr :
>>
>>> Would we expect breakage by such a change?
>>
>> I think that Listen *:NNN is maybe the most common misconfiguration
>> in general, on multihomed boxes (and Listen myhost:NNN not answering
>> the call of localhost being a most common point of confusion :)
>>
>> Your mention of ServerName is a little misleading. A corresponding
>> virtual host isn't needed at all. And mod_ssl handshake is always
>> controlled by the physical vhost (first matching named vhost, name
>> being ignored), which makes this a little more confusing to users.
>
> If understand you correctly, if the first matching (document order?)
> vhost for the address:port (with wildcards) has "SSLEngine on", we
> get mod_ssl engaged. If not, we try to parse a http: request?
>
> Hmmm. That...could be improved.

When the NamedVirtualHost still existed and was still documented,
this was all more obvious to the end-user

This is where it is all explained poorly as features such as '*' were
further modified, so the document is pretty muddy and partly wrong;

http://httpd.apache.org/docs/2.4/vhosts/name-based.html

The author here clearly misunderstood the role of virtual hosts for
directives which affect the initial establishment of the connection
in the read request behavior, prior to re-electing a more specific
name-based vhost match. This sentence in particular could be
corrected; "In first establishing the connection and reading the
request off the wire, and subsequently, If no matching ServerName
or ServerAlias is found in the set of virtual hosts containing the
most specific matching IP address and port combination, then
the first listed virtual host that matches that will be used."

That's more correct but still clumsy, better wordsmithing would
be appreciated. It's answered much better in
http://httpd.apache.org/docs/2.4/mod/core.html#virtualhost

"When a request is received, the server first maps it to the best
matching  based on the local IP address and port
combination only. Non-wildcards have a higher precedence. If no match
based on IP and port occurs at all, the "main" server configuration is
used."

"If multiple virtual hosts contain the best matching IP address and
port, the server selects from these virtual hosts the best match based
on the requested hostname. If no matching name-based virtual host is
found, then the first listed virtual host that matched the IP address
will be used. As a consequence, the first listed virtual host for a
given IP address and port combination is the default virtual host for
that IP and port combination."

But even here we could be more specific in the second para;
"Once the request is received"...

Back to the behavior of mod_ssl, the SSLProtocol directive is
obviously dictated by the physical vhost. But SSLHonorCipherOrder
and other post-SNI decisions? I'm unsure whether the handshake
is "completed" with the SNI name-based election or physical vhost.


>> What leads me to wonder, even with some easier-to-read Listen
>> directives, if the user wouldn't be confused by omission of the
>> SSLEngine on, when their other SSL directives aren't behaving
>> as expected. Because they placed them in the wrong ,
>> obviously. But not obvious to them. The need to toggle SSLEngine
>> may be an unintended usability feature.
>
> I think my gut feeling tells me that "SSLEngine on|off" is more
> part of the port and of the vhost. The vhost may add other SSL*
> configurations, once SNI has identified the correct one. But for
> a certain port (address:port) we either do TLS or not.
>
> So, I was looking for ways to express that and Listen seems a good start.

The protocol tag existed for only one reason, to imply a corresponding
AcceptFilter (e.g. data or no data or http ready on the wire before the
accept would recognize the connection.)

Each time we overload this meaning we are introducing an alternate
or alias to other httpd configuration, which might become confusing
to many users. I just suggest we tread carefully and this time, think
the potential confusion and side effects through.

The other issue IMO is multiple protocols on the given listener.
Already true of http / h2c / h2. A recent proposal suggested to add
PROXY protocol to that list, and the list of potential combinations
goes on.

Re: v1.10.10: fixing stream response getting stuck when writing >32k on a...

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 4:37 AM, Stefan Eissing
 wrote:
>
>> Am 09.08.2017 um 20:32 schrieb Jacob Perkins :
>>
>> Hi Stefan,
>>
>> A patch for 2.4.27 would be great.
>>
>> Your assistance is greatly appreciated.
>
> Gladly. Patch available at: 
> https://github.com/icing/mod_h2/blob/master/patches/mod_h2-v1.10.10-apache-2.4.x.diff

This seems pretty significant for a now GA module? Two thoughts...

Duplicate the patch (against httpd dist) into
www.a.o/dist/httpd/patches/apply_to_2.4.27/ ?

Step up plans to T&R 2.4.28 to supersede the problematic code?

Re: Listen 443 https

[William A Rowe Jr]

Let's break it down and consider the implications of Listen...

On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
 wrote:
> Now that mod_md has landed in trunk, I am looking at more ways
> to simplify a SSL configuration. Looking at the Listen directive,
> it has an optional 2nd protocol parameter.
>
> Would it be unreasonable to assume that a
> Listen NNN https
>
> means that "SSLEngine on" should be the default in all
> 
>ServerName xxx.yyy
>...
> 
>
> sections?

Firstly, we have well understood protocols definitions, so there
are several shorthand flavors that could be introduced;

  Listen https

has a very plain and obvious meaning. Thus, so would these;

  Listen https://192.168.1.1
  Listen https://xxx.yyy
  Listen https://192.168.1.1:8443
  Listen https://xxx.yyy:8443

> Would we expect breakage by such a change?

I think that Listen *:NNN is maybe the most common misconfiguration
in general, on multihomed boxes (and Listen myhost:NNN not answering
the call of localhost being a most common point of confusion :)

Your mention of ServerName is a little misleading. A corresponding
virtual host isn't needed at all. And mod_ssl handshake is always
controlled by the physical vhost (first matching named vhost, name
being ignored), which makes this a little more confusing to users.

What leads me to wonder, even with some easier-to-read Listen
directives, if the user wouldn't be confused by omission of the
SSLEngine on, when their other SSL directives aren't behaving
as expected. Because they placed them in the wrong ,
obviously. But not obvious to them. The need to toggle SSLEngine
may be an unintended usability feature.


> What about name-based virtual hosts that apply to _all_
> addresses and ports? E.g. something like:
> 
>ServerName xxx.yyy
>...
>
>   Redirect permanent "/" "https://xxx.yyy/";
>
>...
> 
>
> Do you find that ugly/feasible/desirable?

Definitely not a fan. Why isn't this rewrite simply given in the system
global config?

A connection, later the request, maps to only VirtualHost declaration.
That block would never fire if there is a matching VirtualHost. OTOH,
if no VirtualHost matches, then we use the global host anyways.

Re: Content-Type / AddOutputFilterByType DEFLATE text/html

[William A Rowe Jr]

This current behavior still seems wrong in httpd. A content (as opposed
perhaps to transfer) should not vary, in fact cannot vary if an etag is
presented.

I suspect that the deflate filter looks to see if there is a benefit to
compression, and cannot do so until it has a body. If it is going to do
that, I suspect it must use a transfer encoding. Otherwise the deflation of
content shouldn't vary, and the header should be toggled even when there is
no body.


On Aug 7, 2017 04:43, "Reindl Harald"  wrote:

> OK, the reason are the HEAD-Requests triggered by curl_setopt($curl,
> CURLOPT_NOBODY, 1); so the bug is ignoring that in case of
> "/static.htm?count=250_150209658" and sending in fact a body back while
> for the 3 other test urls the response is HEAD as requested and the curl
> code is identical
>
>  $curl = curl_init();
>  curl_setopt($curl, CURLOPT_NOBODY, 1);
>  curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
>  curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 5);
>  curl_setopt($curl, CURLOPT_USERAGENT, 'Mozilla/5.0 (X11; Fedora; Linux
> x86_64; rv:55.0) Gecko/20100101 Firefox/55.0');
>  curl_setopt($curl, CURLOPT_HEADER, 1);
>  curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
>  curl_setopt($curl, CURLOPT_URL, $url);
>  curl_setopt($curl, CURLOPT_HTTPHEADER, $curl_header);
>
> Am 07.08.2017 um 11:12 schrieb Reindl Harald:
>
>> Hi
>>
>> AddOutputFilterByType DEFLATE text/html
>>
>> is this a bug or somehow expected behavior that in case the
>> "Content-Type" header also contains a charset mod_defalte don't work as
>> expected which means in case of curl requests only static files are gzip
>> compressed while PHP responses are missing "Content-Encoding: gzip" - that
>> this don't happen in case of Firefox as client makes it even more strange
>>
>> identical result for "Content-Type: text/html; charset=UTF-8" in case
>> "default_charset" is not set in php.ini
>>
>> the last line of each block is the PHP array for curl_setopt($curl,
>> CURLOPT_HTTPHEADER, $curl_header);
>>
>> NO GZIP
>> http://corecms/index.php?count=250_1502096587
>> HTTP/1.1 200 OK
>> Date: Mon, 07 Aug 2017 09:03:08 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=1744 us
>> Expires: Mon, 26 Jul 1997 05:00:00 GMT
>> Cache-Control: no-cache
>> ETag: 7d820de3763d0e6c22ccbfe846ab1c31
>> Vary: User-Agent
>> Content-Type: text/html; charset=ISO-8859-1
>> a:2:{i:0;s:58:"Cookie: LOUNGE_ID=pivked76ocg1n9750n91
>> d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: gzip, deflate";}
>>
>> NO GZIP
>> http://corecms/
>> HTTP/1.1 200 OK
>> Date: Mon, 07 Aug 2017 09:03:08 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=400 us
>> Cache-Control: max-age=120
>> Expires: Mon, 07 Aug 2017 09:05:08 GMT
>> Vary: User-Agent
>> Content-Type: text/html; charset=ISO-8859-1
>> a:2:{i:0;s:58:"Cookie: LOUNGE_ID=pivked76ocg1n9750n91
>> d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: gzip, deflate";}
>>
>> GZIP OK
>> http://corecms/static.htm?count=250_1502096587
>> HTTP/1.1 200 OK
>> Date: Mon, 07 Aug 2017 09:03:08 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=297 us
>> Last-Modified: Sun, 06 Aug 2017 17:49:54 GMT
>> ETag: "ec1-556195b938c8f-gzip"
>> Accept-Ranges: bytes
>> Cache-Control: max-age=120
>> Expires: Mon, 07 Aug 2017 09:05:08 GMT
>> Content-Encoding: gzip
>> Vary: Accept-Encoding
>> Content-Length: 890
>> Content-Type: text/html
>> a:2:{i:0;s:58:"Cookie: LOUNGE_ID=pivked76ocg1n9750n91
>> d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: gzip, deflate";}
>>
>> NO GZIP
>> http://corecms/static.php?count=250_1502096587
>> HTTP/1.1 200 OK
>> Date: Mon, 07 Aug 2017 09:03:08 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=280 us
>> Cache-Control: max-age=120
>> Expires: Mon, 07 Aug 2017 09:05:08 GMT
>> Vary: User-Agent
>> Content-Type: text/html; charset=ISO-8859-1
>> a:2:{i:0;s:58:"Cookie: LOUNGE_ID=pivked76ocg1n9750n91
>> d3dtnqqpqhpmqci63pvo";i:1;s:30:"Accept-Encoding: gzip, deflate";}
>>
>

Re: A little nit

[William A Rowe Jr]

+1.

As an alternative... an execute-on-read directive of ProxyBalancerPrecision
or similarly named directive (default 100, but drop or add decimals as
they will)
would let anyone add in or sub out a decimal.

My thought, taking away 1000 (3 decimal) from 2bn really wouldn't be a
hardship on any common config.

On Sat, Aug 5, 2017 at 2:34 PM, Jim Jagielski  wrote:
> Sounds good to me :)
>
>> On Aug 4, 2017, at 9:02 PM, Jim Riggs  wrote:
>>
>>> On 3 Aug 2017, at 08:30, Jim Jagielski  wrote:
>>>
>>> It's just GUI magic... Basically, it will internally take '1.1' and
>>> convert it to 11, 1.0 to 10, etc...
>>
>> If that's the case, I would recommend going 2 decimal places (1.1 = 100, 
>> 1.25 = 125, etc.) to allow using percentages. I could see people wanting to 
>> be able to favor a backend by 25%, for example, by using 1.25. Any more than 
>> 2 decimal places could be rounded to 2.
>>
>

Re: SSLPolicy

[William A Rowe Jr]

On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing
 wrote:
> I talked about some kind of SSL Policy definition in httpd's configuration
> in the past and am now about to get serious about it. Here is what I wan to
> do:
>
> Recap: the general idea is
> 2. Provide a set of already defined policies that either follow a public
>definition (like the Mozilla security classes) or express our idea of
>how configuration should look like.

I read this aspect at this as more of a weakness than a benefit.

OpenSSL is more likely to be promptly updated by our users than httpd
itself. Where ever httpd is overriding OpenSSL preferences, we will
simply be prolonging the use of discouraged policy.

If a cipher is changed upstream in OpenSSL from HIGH to MEDIUM
strength (or dropped entirely), due to the discovery of a weakness in
the cipher, I believe it is important for httpd to pick up on that signal
without upgrade or recompilation.

Re: svn commit: r1803396 - in /httpd/httpd/trunk: modules/ssl/ support/

[William A Rowe Jr]

IMO that's garbage, please revert. I don't believe that any ASF project,
which has very firm rules about appropriating code bases, should be
tolerating namespace abuse and mark infringement against other
projects.

If they want us to test a symbol in a LIBRESSL space, that's fine, but
OPENSSL namespace was not theirs to begin with.



On Sat, Jul 29, 2017 at 6:05 PM,   wrote:
> Author: ylavic
> Date: Sat Jul 29 23:05:02 2017
> New Revision: 1803396
>
> URL: http://svn.apache.org/viewvc?rev=1803396&view=rev
> Log:
> mod_ssl, ab: compatibility with LibreSSL.  PR 61184.
>
> LibreSSL defines OPENSSL_VERSION_NUMBER = 2.0, but is not compatible with
> all of the latest OpenSSL 1.1 API.
>
> Address this by defining MODSSL_USE_OPENSSL_PRE_1_1_API which is true for
> anything but OpenSSL >= 1.1 (for now).
>
> Proposed by: Bernard Spil 
> Reviewed by: ylavic
>
>
> Modified:
> httpd/httpd/trunk/modules/ssl/mod_ssl.c
> httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
> httpd/httpd/trunk/modules/ssl/ssl_private.h
> httpd/httpd/trunk/modules/ssl/ssl_util.c
> httpd/httpd/trunk/modules/ssl/ssl_util_ssl.h
> httpd/httpd/trunk/support/ab.c
>
> Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1803396&r1=1803395&r2=1803396&view=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
> +++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Sat Jul 29 23:05:02 2017
> @@ -354,7 +354,7 @@ static apr_status_t ssl_cleanup_pre_conf
>  #endif
>
>  /* Usually needed per thread, but this parent process is single-threaded 
> */
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if MODSSL_USE_OPENSSL_PRE_1_1_API
>  #if OPENSSL_VERSION_NUMBER >= 0x100fL
>  ERR_remove_thread_state(NULL);
>  #else
> @@ -398,15 +398,15 @@ static int ssl_hook_pre_config(apr_pool_
>  /* Some OpenSSL internals are allocated per-thread, make sure they
>   * are associated to the/our same thread-id until cleaned up.
>   */
> -#if APR_HAS_THREADS && OPENSSL_VERSION_NUMBER < 0x1010L
> +#if APR_HAS_THREADS && MODSSL_USE_OPENSSL_PRE_1_1_API
>  ssl_util_thread_id_setup(pconf);
>  #endif
>
>  /* We must register the library in full, to ensure our configuration
>   * code can successfully test the SSL environment.
>   */
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> -CRYPTO_malloc_init();
> +#if MODSSL_USE_OPENSSL_PRE_1_1_API
> +(void)CRYPTO_malloc_init();
>  #else
>  OPENSSL_malloc_init();
>  #endif
>
> Modified: httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c?rev=1803396&r1=1803395&r2=1803396&view=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c Sat Jul 29 23:05:02 2017
> @@ -32,7 +32,7 @@ static apr_status_t verify_signature(sct
>  return APR_EINVAL;
>  }
>
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
>  ctx = EVP_MD_CTX_create();
>  #else
>  ctx = EVP_MD_CTX_new();
> @@ -41,7 +41,7 @@ static apr_status_t verify_signature(sct
>  ap_assert(1 == EVP_VerifyUpdate(ctx, sctf->signed_data,
>  sctf->signed_data_len));
>  rc = EVP_VerifyFinal(ctx, sctf->sig, sctf->siglen, pkey);
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
>  EVP_MD_CTX_destroy(ctx);
>  #else
>  EVP_MD_CTX_free(ctx);
>
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1803396&r1=1803395&r2=1803396&view=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Sat Jul 29 23:05:02 2017
> @@ -50,7 +50,7 @@ APR_IMPLEMENT_OPTIONAL_HOOK_RUN_ALL(ssl,
>  #define KEYTYPES "RSA or DSA"
>  #endif
>
> -#if OPENSSL_VERSION_NUMBER < 0x1010L
> +#if MODSSL_USE_OPENSSL_PRE_1_1_API
>  /* OpenSSL Pre-1.1.0 compatibility */
>  /* Taken from OpenSSL 1.1.0 snapshot 20160410 */
>  static int DH_set0_pqg(DH *dh, BIGNUM *p, BIGNUM *q, BIGNUM *g)
> @@ -253,7 +253,7 @@ apr_status_t ssl_init_Module(apr_pool_t
>  #endif
>  }
>
> -#if APR_HAS_THREADS && OPENSSL_VERSION_NUMBER < 0x1010L
> +#if APR_HAS_THREADS && MODSSL_USE_OPENSSL_PRE_1_1_API
>  ssl_util_thread_setup(p);
>  #endif
>
> @@ -380,7 +38

Re: A little nit

[William A Rowe Jr]

On Wed, Aug 2, 2017 at 12:33 PM, Jim Jagielski  wrote:
> I'll be adding some code to allow for lbfactors to be
> single decimal numbers (like 1.1, 2.5, etc...)... People
> have asked "How do I change it so that machine B is like 10%
> preferred" and I mention that "Well, you could make one a
> 10 and the other an 11" but that confuses people. :/

Are we changing the lb member structures to force recompilation of all
non-core lbproviders and consumers in a subsequent 2.4.x release and
introducing more binary breakage?

Or do you envision keeping this in trunk for 2.next, or making this entirely
cosmetic (same intregal struct member, at a multiplication of 10n) in the
proxypass / balancer parameter config logic? Since that config logic is
entirely in core/proxy_balancer, it should be transparent to lbproviders
and consumers.

Re: svn commit: r1803072 - /httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl

[William A. Rowe Jr.]

Yup, thanks for the follow-up!  Site is updated and links to
security_vuln24.html#CVE-2017- will now resolve to a sensible place on
our vuln lists.



On Jul 26, 2017 18:07, "Greg Stein"  wrote:

> Hey Bill,
>
> There was a misconfigured LDAP server ... that was fixed earlier today, so
> you should be good to go now!
>
> Cheers,
> -g
>
>
> On Wed, Jul 26, 2017 at 2:53 PM, William A Rowe Jr 
> wrote:
>
>> I would push this edit live (looking good from a local regen here), but
>> https://cms.a.o has been down for a number of hours. bcc'ing root@
>> so that they are aware that we've lost that control panel, @infrabot
>> hasn't posted a status on the service.
>>
>> Cheers,
>>
>> Bill
>>
>> > Author: wrowe
>> > Date: Wed Jul 26 16:30:47 2017
>> > New Revision: 1803072
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1803072&view=rev
>> > Log:
>> > Generate A-name tag for CVE entries, follow sp-slash-gt pattern for
>> output html
>> >
>> > Modified:
>> > httpd/site/trunk/content/security/vulnerabilities-httpd.
>> page/securitydb.xsl
>>
>
>

Re: svn commit: r1803072 - /httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl

[William A Rowe Jr]

I would push this edit live (looking good from a local regen here), but
https://cms.a.o has been down for a number of hours. bcc'ing root@
so that they are aware that we've lost that control panel, @infrabot
hasn't posted a status on the service.

Cheers,

Bill

> Author: wrowe
> Date: Wed Jul 26 16:30:47 2017
> New Revision: 1803072
>
> URL: http://svn.apache.org/viewvc?rev=1803072&view=rev
> Log:
> Generate A-name tag for CVE entries, follow sp-slash-gt pattern for output 
> html
>
> Modified:
> 
> httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl

CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest

[William A Rowe Jr]

CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
all versions through 2.2.33 and 2.4.26

Description:
The value placeholder in [Proxy-]Authorization headers
of type 'Digest' was not initialized or reset
before or between successive key=value assignments.
by mod_auth_digest
Providing an initial key with no '=' assignment
could reflect the stale value of uninitialized pool
memory used by the prior request, leading to leakage
of potentially confidential information, and a segfault

Mitigation:
All users of httpd should upgrade to 2.4.27 (or minimally
2.2.34, which will receive no further security releases.)
Alternately, the administrator could configure httpd to
reject requests with a header matching a complex regular
expression identifing where = character does not occur
in the first key=value pair, as in the following syntax;
[Proxy-]Authorization: Digest key[,key=value]

Credit:
The Apache HTTP Server security team would like to thank Robert Święcki
for reporting this issue.

References:
https://httpd.apache.org/security_report.html

CVE-2017-9789: Read after free in mod_http2

[William A Rowe Jr]

CVE-2017-9789: Read after free in mod_http2

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
httpd 2.4.26

Description:
When under stress, closing many connections, the HTTP/2
handling code would sometimes access memory after it has
been freed, resulting in potentially erratic behaviour.

Mitigation:
2.4.26 users of mod_http2 should upgrade to 2.4.27.

Credit:
The Apache HTTP Server security team would like to thank Robert Święcki
for reporting this issue.

References:
https://httpd.apache.org/security_report.html

Re: [Announcement] Apache HTTP Server 2.2.34 Released

[William A Rowe Jr]

On Wed, Jul 12, 2017 at 4:47 AM, Daniel  wrote:
> Hello,
>
> Just FYI
>
> http://httpd.apache.org/download.cgi is still pointing to 2.2.32
> version and thus gives a 404 when trying to download.

Thanks for the report! Now fixed.

[Announcement] Apache HTTP Server 2.2.34 Released

[William A Rowe Jr]

  July 11, 2017

   The Apache Software Foundation and the Apache HTTP Server Project
   announce the release of version 2.2.34 of the Apache HTTP Server
   ("Apache"), the final maintenance release of the 2.2 series. No
   further 2.2 releases are anticipated. This version of Apache is
   principally a security and bug fix maintenance release.

   We consider the current Apache HTTP Server 2.4 release to be the best
   version of Apache available, and encourage every user of 2.2 and all
   prior versions to upgrade. This final 2.2 release is offered for those
   unable to upgrade at this moment.

   Take note that Apache Web Server Project will provide no future release
   of the 2.2.x series, although some security patches may be published
   through December of 2017. These will be collected at the URL;

 http://www.apache.org/dist/httpd/patches/apply_to_2.2.34/

   No further maintenance patches of 2.2.x will be published. Users are
   strongly encouraged to promptly complete their transitions to the
   2.4.x flavor of httpd to receive any future benefit from the user
   community or the Apache HTTP Server project developers.

   For further details about the currently supported release, see:

 http://www.apache.org/dist/httpd/Announcement2.4.txt

   Apache HTTP Server 2.4 and 2.2.34 are available for download from:

 http://httpd.apache.org/download.cgi

   Please see the CHANGES_2.2 file, linked from the download page, for a
   full list of changes. A condensed list, CHANGES_2.2.34 includes only
   those changes introduced since the prior 2.2 release. A summary of all
   of the security vulnerabilities addressed in this and earlier releases
   is available:

 http://httpd.apache.org/security/vulnerabilities_22.html

   Note that the Apache HTTP Server project will discontinue evaluations
   and corresponding advisories to this resource effective January, 2018.

   This release includes the Apache Portable Runtime (APR) version 1.5.2
   and APR Utility Library (APR-util) version 1.5.4, bundled with the tar
   and zip distributions. The APR libraries libapr and libaprutil (and
   on Win32, libapriconv version 1.2.1) must all be updated to ensure
   binary compatibility and address many known security and platform bugs.
   APR version 1.5 and APR-util version 1.5 represent minor version upgrades
   from earlier httpd 2.2 source distributions.

   Note this package also includes very stale and known-vulnerable versions
   of the Expat [http://expat.sourceforge.net/] and PCRE [http://www.pcre.org/]
   packages. Users are strongly encouraged to first install the most recent
   versions of these components (of PCRE 8.x, not PCRE2 10.x at this time.)

   This release builds on and extends the Apache 2.0 API and is superceeded
   by the Apache 2.4 API. Modules written for Apache 2.2 will need to be
   recompiled in order to run with Apache 2.4, and most will require minimal
   or no source code changes.

Re: httpd 2.4.26 with apr 1.6 ExtFilterDefine

[William A Rowe Jr]

I am very confused, examined apr 1.6 threadproc deltas, now looking at the
mpm, but reporter isolated to apr. Next place I plan to look is is the
fileio abstraction.

I am beginning to suspect this is 'that customer'... In my experience, the
one who duct tapes and binds in entirely unrelated shared libs on Windows
and hopes they will work. If they are passing around apr_os_ objects, they
simply won't when the C Runtime flavors differ.

But, that isn't the entire problem, an executed external process should be
independent of the parent process Runtime. Unless a wrong msvcrt.dll is
wedged in the PATH.

Steffen this one sounds like something your user community could refute or
confirm, and help narrow.


On Jul 8, 2017 3:00 AM, "Steffen"  wrote:

> Received more details:
>
> Our client/server system needs encrypting to client.
> Almost files are statically encrypt, but some xml need to
> modify by SSI then encrypt. So I made encrypting file
> filter by exe (not Apache module). Its name is encect.exe
> (x86) and it is using msvcrt.dll. Because encect.exe works
> all Apache HTTP Server (x86/x64) which is enabled built-in
> mod_ext_filter module.
>
> (Details)
>
> Some directory uses SYMLINKDed directory. Apache HTTP
> Server too. Enabed symlink by .htaccess file in parent of
> symlink.
>
>Options +FollowSymLinks
>
> The modification & encrypt SSI template xml file are in
> the above symlinked directory.
>
> Apache HTTP Server's httpd.conf defines like follow.
>
> ExtFilterDefine ENCECT mode=output cmd=modules/encect.exe
> Alias /WebRoot/ "/Path/To/WebRoot/"
> 
>  Options Indexes MultiViews IncludesNOEXEC
>  AddOutputFilter INCLUDES m3s inc ini
>  AddOutputFilter INCLUDES;ENCECT xmlpp
>  AllowOverride All
>  Require all granted
> 
>
> The xmlpp file size is 3,295 bytes. written in Shift_JIS.
> Used SSI tag is three  like
> follow.
>
>/...
>
> Client access to xmlpp file, the encect.exe process is
> remains in service. I'm memory dump encect.exe and load to
> WinDbg. Call stack is ReadFile(), it means encect.exe
> waiting stdin, but Apache does not send any. Kill the
> encect.exe, client receives body from first SSIed parsed
> text. (Loose until first SSI tag.)
>
> I tested INCLUDE;ENCECT to..
> (A) INCLUDES only, client receives plain complete SSI
> parsed xmlpp file. OK.
> (B) ENCECT only, client receives responce header without
> body. NG. This must encrypt xmlpp file.
>
> Next, I tested mod_ext_filter.so to 2.4.25, but still NG.
>
> Next, I read Apache HTTP Server Change log, I found
> mod_filter changes. I tested mod_filter.so and
> mod_ext_filter.so to 2.4.25, NG.
>
> Next, I tested httpd.exe to 2.4.25, NG.
>
> Next, I read Apache Lounge's used modules, I found APR is
> upgraded to 1.6.2 from 1.5.x. So I tested libapr-1.dll,
> libaprutil-1.dll to 2.4.25, OK! Works like 2.4.25 and
> earlier version of Apache HTTP Server.
>
>
>
> On Friday 07/07/2017 at 20:13, William A Rowe Jr wrote:
>
> On Fri, Jul 7, 2017 at 7:13 AM, Jim Jagielski  wrote:
>
> 2.4.26/27 doesn't *require* APR/APU 1.6.x, but there are
> some features that depend on it. If it's a bug in apr 1.6.x,
> then it's not a httpd bug specifically... imo at least.
>
> any further detail on how the below is actually borken??
> What happens?
>
> On Jul 7, 2017, at 7:41 AM, Steffen  wrote:
>
>
> I got the following report. Is this known ?
>
>
> Because apache http server all of 2.4.26 (vc11,vc14,vc15)
> was not work ExtFilterDefine & OutputFilter. Its bug
> exists in apr 1.6. I thought it need to inform.
>
> Apache 2.4.26 changes apr 1.6, but it broke
> ExtFilterDefine & OutputFilter.
> (test) copy apache 2.4.25's libapr-1 & libaprutil to
> apache 2.4.26, they worked correctly like before apaches.
>
>
> Yes, we need the actual error messages.
>
> I'm about ready to T&R apr 1.6.1 / apu 1.6.3 for the various fixes already
> present, but if we can fix something specific that we are unaware of...
>
>
>

Re: An ask for eyes on proposal

[William A Rowe Jr]

Based on the fact that Jim's advanced this for consideration for 2.4.28,
any further feedback on the following proposal to make RemoteIPProxyProtocol
directive into a whitelist (to compliment the current blacklist directive)? E.g.
in the spirit of the protocol, assign specific remote ip consumers to the list
of those where we accept PROXY protocol wrapping?


On Fri, Jun 9, 2017 at 8:29 AM, William A Rowe Jr  wrote:
> On Fri, Jun 9, 2017 at 4:17 AM, Sander Hoentjen  wrote:
>> On 06/08/2017 07:30 PM, Daniel Ruggeri wrote:
>>> Hi, all;
>>> With the proposal to T&R set for Monday, I wanted to draw attention to
>>> the PROXY protocol proposal in STATUS. Just hoping for a quick review.
>>> I know it appears to be a large change, but as I worked through the
>>> feedback, ten of the commits effectively got coded out. What we are
>>> left with is essentially just the donated code + safety around IPv6 +
>>> the ability to designate subnets that do not get PROXY processing.
>>
>> [...] I still believe it would be better to specify enabling
>> Proxy Protocol on a server, not vhost level. Because well, once you
>> enable it in one vhost it gets enabled for all vhosts using that port/ip
>> combination.
>>
>> Here is what I said before about it:
>>
>> Right now the patch proposes RemoteIPProxyProtocol inside a vhost config, 
>> but wouldn't it be better (since it is connection-specific) to have 
>> something like a ProxyProtocolListen directive? Where you say instead of:
>> --
>> 
>> RemoteIPProxyProtocol On
>> 
>> --
>> Something like:
>> --
>> ProxyProtocolListen 127.0.0.1:9001
>> or
>> ProxyProtocolEnable 127.0.0.1:9001
>> --
>>
>> IMHO this is much cleaner than within a vhost (because that has side-effects 
>> on other vhosts as well)
>
> As this lives in mod_remoteip (for better or worse) let's look at what
> context mod_remoteip is configured in; we set up a list of those local
> or global *client* IP's which we trust to provide legit x-f-f (or remote-ip
> or otherly named) true IP address header fields.
>
> in the PROXY protocol case, we configure which *client* IP's which
> we *require* to submit a PROXY protocol line. Right now, we do that
> as a RemoteIPProxyProtocolExceptions list of those which we do *not*
> allow to submit a PROXY protocol line. I proposed we make the config
> simpler, in theory, by listing those we will trust.
>
> To your example, the *global* config line;
>
> RemoteIPProxyProtocol 127.0.0.1  [or 127.0.0.0/24]
>
> would configure all locally routed *client* requests, irrespective of
> which by-IP vhost, to require the PROXY protocol line. Requests
> from other hosts would be denied.
>
> I think that's sufficient. But if we wanted to implement your basic
> idea, we would still have the complication that we need to infer
> whether 9001 is a http, https, or h2 listener following the PROXY
> line processing. Your proposed syntax didn't really touch on that.
>
> It is still possible to override behavior by-vhost (ip-based, we are
> unprepared to read the TLS SNI or Host header at that point)
> but I don't see any application to do so. A given client is either
> an haproxy or similar, or it is not.

[RESULT] [VOTE] Release httpd-2.2.34

[William A Rowe Jr]

On Thu, Jul 6, 2017 at 2:33 PM, William A Rowe Jr  wrote:
> For your consideration... pre-release candidate tarballs of
> Apache legacy httpd 2.2.34 can be found in;
>
> http://httpd.apache.org/dev/dist/
>
> Thanks all who merged the security work in and other fixes,
> and helped identify a couple more lingering defects.
>
> As we picked end of maintenance Jul 1 '17 - the [discuss]
> thread had sufficient time for response - and no other 2.4
> regressions relate to what has been ported to 2.2... it looks
> like this is the second attempt at 2.2's final hurrah...
>
> Your votes on two decisions, please?
>
> +/-1
> [ ] Release 2.2.34 as legacy GA

Passes 6 +1/no -1. Thanks for reviewing!



> [ ] Retire the 2.2.x branch from any further maintenance.

Passes 5 +1/one -0.

Yann's comment was noted, we as a development community
could look at an especially egregious security defect and decide
it was necessary to make a release. But in the interim, we can
stick with

Re: httpd 2.4.26 with apr 1.6 ExtFilterDefine

[William A Rowe Jr]

On Fri, Jul 7, 2017 at 7:13 AM, Jim Jagielski  wrote:
> 2.4.26/27 doesn't *require* APR/APU 1.6.x, but there are
> some features that depend on it. If it's a bug in apr 1.6.x,
> then it's not a httpd bug specifically... imo at least.
>
> any further detail on how the below is actually borken??
> What happens?
>
>> On Jul 7, 2017, at 7:41 AM, Steffen  wrote:
>>
>>
>> I got the following report. Is this known ?
>>
>>
>> Because apache http server all of 2.4.26 (vc11,vc14,vc15)
>> was not work ExtFilterDefine & OutputFilter. Its bug
>> exists in apr 1.6. I thought it need to inform.
>>
>> Apache 2.4.26 changes apr 1.6, but it broke
>> ExtFilterDefine & OutputFilter.
>> (test) copy apache 2.4.25's libapr-1 & libaprutil to
>> apache 2.4.26, they worked correctly like before apaches.

Yes, we need the actual error messages.

I'm about ready to T&R apr 1.6.1 / apu 1.6.3 for the various fixes already
present, but if we can fix something specific that we are unaware of...

[VOTE] Release httpd-2.2.34

[William A Rowe Jr]

For your consideration... pre-release candidate tarballs of
Apache legacy httpd 2.2.34 can be found in;

http://httpd.apache.org/dev/dist/

Thanks all who merged the security work in and other fixes,
and helped identify a couple more lingering defects.

As we picked end of maintenance Jul 1 '17 - the [discuss]
thread had sufficient time for response - and no other 2.4
regressions relate to what has been ported to 2.2... it looks
like this is the second attempt at 2.2's final hurrah...

Your votes on two decisions, please?

+/-1
[ ] Release 2.2.34 as legacy GA

+/-1
[ ] Retire the 2.2.x branch from any further maintenance.

Note .tar contains apr 1.5.2, apr-util 1.5.4 while -win32-src.zip
also contains apr-iconv 1.2.1, in keeping with 2.2 conventions.
New language in INSTALLING and additional language in the
Announcement warns users away from the also bundled PCRE
and Expat sources, in favor of current releases.

Please also refer to the Announcement2.2.txt(.html) at the URL
above for suggesting edits, all improvements welcomed!

[WITHDRAWN] [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

On Fri, Jun 23, 2017 at 5:19 PM, William A Rowe Jr  wrote:
> For your consideration... pre-release candidate tarballs of
> Apache legacy httpd 2.2.33 can be found in;
>
> http://httpd.apache.org/dev/dist/

To make things clear, this call for [VOTE] is withdrawn based
on the regression observed in 2.2.32 and fixed for 2.2.34.

Re: 2.4.27

[William A Rowe Jr]

On Thu, Jul 6, 2017 at 12:28 PM, Jacob Champion  wrote:
>
> Administrators using prefork who would like to switch to HTTP/2 in the
> future need to understand the limitations of the prefork architecture they
> have selected. And sure, our users can request that we implement a solution
> that "just works" with prefork, with the parent dispatcher that Stefan has
> mentioned, and we can weigh the cost/benefit of implementing it. But IMO
> it's not that onerous to ask our users to upgrade to a modern MPM if they
> want a nice new protocol.

Agreed. Handling connections and requests on a 1:1 basis gains little from h2
protocol, other than a different path to TLS handshaking. As the h2 protocol
corrupted the OSI model and wire format in the first place, clients are forced
to deterministically wiggle their way into an h2 connection without telegraphing
that dance to the end-user. So this should be completely opaque to the client's
user, and similarly opaque to the server admin.

The parent (root) process can never serve as the actual traffic dispatcher,
much too risky. So the parent or a dedicated spawned process (preferable)
would have to triage all the requests for child workers to an h2 connection
by dispatching unix domain sockets between the connection's worker and
the individual request workers, and then let them exchange data through
the socket, because shared memory between connection and request
workers would not behave the same way.

In short, it would be an entirely new level of complexity, which the current
project maintainers have no interest in engaging in. This worked with the
mod_ftp only because the control channel (similar to the connection thread)
has absolutely nothing to do during the singular data channel exchange,
other than be watched for an ABOR; no other command is valid. h2 needs
to lookaside for control directives from the connection channel while it is
servicing each of the request workers.

Prefork exists only because http/1 is a synchronous protocol, in that the
server reads the user-agent's instructions and is left to act on that method
and resource, with no other client interaction other than 101 continue or
102 upgrade (101 was especially disruptive but still largely ping-pong.)
If the original protocol were http/2, prefork would never have been introduced.

It's 2017. I've been threading my logic now over 30 years. Maybe it's time
that Unix library developers and php community wake up to a new century?
But as long as the fastcgi model persists, there is really no need to worry
about any of this; run a threaded server and an fcgi pool of php app servers.

Re: 2.4.27

[William A Rowe Jr]

On Thu, Jul 6, 2017 at 12:20 PM, Helmut K. C. Tessarek
 wrote:
> On 2017-07-06 13:09, Reindl Harald wrote:
>> with removing mpm_prefork support for H2 you kill HTTP2 support for a
>> lot of production setups which may consider switch to H2 in the future
>> and for sure not rework there whole configuration but put a proxy like
>> Trafficserver in front and forget about httpd at this point at all
>
> I respectfully disagree.
>
> Removing h2 on prefork solves all issues that arise when used in this
> context. You don't put diesel in your car, when your engine is for
> regular gas. Why? Because it won't work and might screw up your engine.
>
> Same applies to h2 and prefork.

Well put. Confirming what Stefan wrote... the following appears in the error log
at startup;

[Thu Jul 06 12:18:58.005442 2017] [http2:warn] [pid 30121] AH10034:
The mpm module (prefork.c) is not supported by mod_http2. The mpm
determines how things are processed in your server. HTTP/2 has more
demands in this regard and the currently selected mpm will just not
do. This is an advisory warning. Your server will continue to work,
but the HTTP/2 protocol will be inactive.

Go ahead and build all mpm's - default to prefork, enable http2. Nothing
is wrong, but http:// connections won't transition to h2, that is all.

Building prefork also doesn't disable mod_http2 by default, which is good,
because I would expect that to cause http2 to not be built when building all
mpm's in one go.

The 2.4 tree looks good for tagging.

Re: 2.4.27

[William A Rowe Jr]

+1 to removing support of mom prefork. I'd prefer it still start and if
configured, with an [error] level alert in the logs and simply be disabled.
Server must start when module is loaded but not configured, e.g. in test
framework, IMO.

On Jul 6, 2017 10:31 AM, "Stefan Eissing" 
wrote:

> Correction: websockets are not defined over h2. To make a more "real life"
> scenario:
>
> One example is a long polling request by a javascript component. During
> the long poll, the browser will not get other responses.
>
> More esoteric: when content filters (brotli, gzip) are in place,
> compression happens in the h2 worker thread. If one PUSHes such a resource,
> clients sometimes use h2 flow control to delay the sending of a response.
> This would deadlock the connection in a prefork model.
>
> These are complications not easily debugged or reproducible.
>
> > Am 06.07.2017 um 17:15 schrieb Stefan Eissing <
> stefan.eiss...@greenbytes.de>:
> >
> > Hej,
> >
> > I tried to gather some discussion about this. Should have polled this
> mailing list. You can read most of it here: https://github.com/icing/mod_
> h2/issues/142
> >
> > tl;dr
> >
> > I had several reports in the past of people being disappointed about h2
> performance, only to learn they were on prefork. Which means every request
> is processed serially (with static files being an exception, as long as no
> filters prevent this).
> >
> > In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers,
> which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in
> the config and you have the pre-2.4.26 behaviour.
> >
> > Regardless of the discussion if the change in 2.4.26 was reasonable or
> not: it is not possible to map the prefork single-thread requirement on to
> HTTP/2. Not going to work. One long running request, one websocket opened,
> and your browser will stall.
> >
> > This is not a bug, it is the collision of the processing models.
> >
> > So, I think disabling it prevent user from shooting themselves in the
> foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1
> connections, not h2.
> >
> > Does this make sense?
> >
> > Cheers,
> >
> > Stefan
> >
> > PS. Yes, I know that one /could/ make parallel processes work in prefork
> by placing the h2 dispatching in a parent process. If someone wants to
> implement that, be my guest.
> >
> >
> >> Am 06.07.2017 um 16:55 schrieb Bert Huijben :
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Jim Jagielski [mailto:j...@jagunet.com]
> >>> Sent: woensdag 5 juli 2017 18:49
> >>> To: dev@httpd.apache.org
> >>> Subject: Re: 2.4.27
> >>>
> >>> These are just the fixes/regressions noted in CHANGES:
> >>>
> >>> Changes with Apache 2.4.27
> >>>
> >>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
> >>>PR58188, PR60831, PR61245. [Rainer Jung]
> >>>
> >>> *) mod_http2: disable and give warning when mpm_prefork is
> >>> encountered. The server will
> >>>continue to work, but HTTP/2 will no longer be negotiated. [Stefan
> >> Eissing]
> >>
> >> Can somebody point me to the reasoning behind this?
> >>
> >> I have this configuration on FreeBSD with older Httpd versions, and it
> works
> >> just fine for my limited load.
> >>
> >> Switching to a different model will require compiling more ports myself
> as
> >> the FreeBSD packaging system is optimized for this model.
> >>
> >>
> >> I do understand that there is a better mapping of http/2 streams with
> the
> >> more modern MPMs, but there must be a reason that it worked and no
> longer
> >> can be supported in the future. I assume this reason is already
> documented
> >> somewhere...
> >>
> >> Thanks,
> >>
> >>  Bert
> >>
> >>
> >
>
>

Test case intermittent failure?

[William A Rowe Jr]

t/apache/expr_string.t(Wstat: 0 Tests: 23 Failed: 1)
  Failed test:  14

# writing file:
/home/wrowe/dev/test/test2x-apr20-ossl110/t/htdocs/apache/expr/.htaccess
ok 12
Expected return code 200, got 200 for '}'
ok 13
Got '}', expected '}'
ok 14

Any reason I should expect an intermittent failure here?
Observed only once, -vebose as seen above was clean.
Any changes recently that might change the frequency?

Re: 2.4.27

[William A Rowe Jr]

+1

On Jul 3, 2017 6:33 AM, "Jim Jagielski"  wrote:

> Anyone opposed to a quick T&R and release of 2.4.27 within
> the next week?
>

Re: FastCGI env-vars

[William A Rowe Jr]

I'm reading https://tools.ietf.org/html/rfc3875#section-4.1.5 as the
PATH_INFO is entirely distinct from QUERY_STRING.

On Sun, Jul 2, 2017 at 10:08 AM, Jim Jagielski  wrote:
> There is one (I hope!) final question... There seems to be
> conflicting interpretations on whether PATH_INFO should, or
> should NOT, include any QUERY_STRING info or "extra stuff"
> after the actual path itself...
>
> Right now, we don't.

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

[William A Rowe Jr]

You already have my unconditional +1 to bring us back to a trusted state.

On Jun 30, 2017 16:55, "Jacob Champion"  wrote:

> On 06/30/2017 11:40 AM, Jacob Champion wrote:
>
>> As far as I can tell it has no downsides, so my only request is that we
>> add it to CHANGES (or some documentation, somewhere) and get a test in
>> place before it goes back in. I may be able to get to that later this
>> afternoon.
>>
>
> This is taking me longer than I wanted, so in the interest of time, I've
> just gone ahead and added the un-revert to the backport proposal. I hope to
> get to the tests for it next week.
>
> Regression tests still pass for me; vote away!
>
> --Jacob
>

Re: svn commit: r1800307 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

-1 on showstopper. It's a bug, no security implications, cope with it.

Thousands of bugs pass through STATUS, what makes yours special?

That said, unconditional +1 to any mod_proxy_fcgi.c patches you or Jim or
any committers determine for backport, I'd prefer we treat the module as
experimental until it behaves how we desire and in any way compatible with
PHP's tomfoolery.


On Jun 29, 2017 1:06 PM,  wrote:

> Author: jchampion
> Date: Thu Jun 29 18:06:49 2017
> New Revision: 1800307
>
> URL: http://svn.apache.org/viewvc?rev=1800307&view=rev
> Log:
> Propose showstopper.
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> STATUS?rev=1800307&r1=1800306&r2=1800307&view=diff
> 
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Thu Jun 29 18:06:49 2017
> @@ -112,6 +112,12 @@ CURRENT RELEASE NOTES:
>
>  RELEASE SHOWSTOPPERS:
>
> +  *) PR61202: remove FPM-specific logic from mod_proxy_fcgi. Returns us to
> + 2.4.20 FCGI behavior by default.
> + trunk patch: https://svn.apache.org/r1800306
> + 2.4.x patch: trunk works, modulo APLOGNO and CHANGES
> + +1: jchampion
> +
>
>  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
>[ start all new proposals below, under PATCHES PROPOSED. ]
>
>
>

Re: svn commit: r1800162 - in /httpd/test/framework/trunk/t: conf/extra.conf.in modules/proxy.t

[William A Rowe Jr]

On Wed, Jun 28, 2017 at 8:08 AM,   wrote:
> Author: jim
> Date: Wed Jun 28 13:08:41 2017
> New Revision: 1800162
>
> --- httpd/test/framework/trunk/t/modules/proxy.t (original)
> +++ httpd/test/framework/trunk/t/modules/proxy.t Wed Jun 28 13:08:41 2017
> @@ -7,7 +7,7 @@ use Apache::TestUtil;
>  use Apache::TestConfig ();
>  use Misc;
>
> -my $num_tests = 20;
> +my $num_tests = 21;
>  if (have_min_apache_version('2.4.7')) {
>  $num_tests++;
>  }
> @@ -119,8 +119,8 @@ sub uds_script
>  if (accept(my $new_sock, $server)) {
>  my $data = <$new_sock>;
>  print $new_sock "HTTP/1.0 200 OK\r\n";
> -print $new_sock "Content-Type: text/html\r\n\r\n";
> -print $new_sock "Hello 
> World$data\n";
> +print $new_sock "Content-Type: text/plain\r\n\r\n";
> +print $new_sock "hello world\n";
>  close $new_sock;
>  }
>  unlink($socket_path);
> @@ -145,5 +145,9 @@ if (have_min_apache_version('2.4.7')) {
>  }
>  $r = GET("/uds/");
>  ok t_cmp($r->code, 200, "ProxyPass UDS path");
> +my $c = $r->content;
> +chomp $c;
> +ok t_cmp($c, "hello world", "UDS content OK");
> +
>  }
>
>

That's problematic, your counting was skewed;

t/modules/proxy.t ... Failed 1/21 subtests
(less 3 skipped subtests: 17 okay)

I expect you wanted to tickle the count += 2 in place of ++ in the line below?

t/modules/proxy_fcgi.t .. Can't exec "php-fpm": No such
file or directory at t/modules/proxy_fcgi.t line 11.
t/modules/proxy_fcgi.t .. skipped: cannot find module
'mod_proxy_fcgi'

This one is odd, shouldn't we skip all proxy_fcgi.t the moment
mod_proxy_fcgi is absent, rather that hunting for the php-fpm
component?

Re: svn commit: r1800181 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

Actually, I should have backed out rpluem's vote for the original one line
patch.

Can we get one more pair of eyeballs (or cross-vote the other branch) so
this is properly accepted?


On Jun 28, 2017 10:49,  wrote:

> Author: ylavic
> Date: Wed Jun 28 15:49:07 2017
> New Revision: 1800181
>
> URL: http://svn.apache.org/viewvc?rev=1800181&view=rev
> Log:
> Vote, promote.
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> STATUS?rev=1800181&r1=1800180&r2=1800181&view=diff
> 
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Wed Jun 28 15:49:07 2017
> @@ -116,6 +116,15 @@ RELEASE SHOWSTOPPERS:
>  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
>[ start all new proposals below, under PATCHES PROPOSED. ]
>
> +   *) Restore single-char field names inadvertantly disallowed in 2.4.25.
> +  Message ID:  4eap0zjsz42j_vuzv2s...@mail.gmail.com>
> +  Backports: r1800173
> +  PR: 61220
> +  Submitted by: ylavic
> +  trunk patch: http://svn.apache.org/r1800173 (mod CHANGES)
> +  2.4 patch: trunk works
> +  +1: wrowe, rpluem, ylavic
> +
>
>  PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>[ New proposals should be added at the end of the list ]
> @@ -218,13 +227,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>2.4.x patch: svn merge -c 
> 1551611,1783765,1788996,1788998,1789000,1795651
> ^/httpd/httpd/trunk .
>+1: jailletc36, jim
>
> -   *) Restore single-char field names inadvertantly disallowed in 2.2.32.
> -  Backports: r1800173
> -  PR: 61220
> -  Submitted by: ylavic
> -  trunk patch: http://svn.apache.org/r1800173 (mod APLOGNO plus
> CHANGES)
> -  2.2 patch: Message ID:  4eap0zjsz42j_vuzv2s...@mail.gmail.com>
> -  +1: wrowe, rpluem
>
>  PATCHES/ISSUES THAT ARE BEING WORKED
>[ New entries should be added at the START of the list ]
>
>
>

Re: svn commit: r1800111 - /httpd/httpd/trunk/server/protocol.c

[William A Rowe Jr]

On Wed, Jun 28, 2017 at 7:14 AM, Yann  wrote:
>
> Looks like the code after the patch below would be simpler and work too :

Agreed this is easier to follow, tmp_field is otherwise unused in the
unsafe code path. Proposed for backport, thanks.

Note this patch is the 2.2, non-APLOGNO flavor;

> Index: server/protocol.c
> ===
> --- server/protocol.c(revision 1800151)
> +++ server/protocol.c(working copy)
> @@ -1081,8 +1081,12 @@ AP_DECLARE(void) ap_get_mime_headers_core(request_
>  return;
>  }
>
> -/* last character of field-name */
> -tmp_field = value - (value > last_field ? 1 : 0);
> +if (value == last_field) {
> +r->status = HTTP_BAD_REQUEST;
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
> +  "Request header field name was empty");
> +return;
> +}
>
>  *value++ = '\0'; /* NUL-terminate at colon */
>
> @@ -1105,13 +1109,6 @@ AP_DECLARE(void) ap_get_mime_headers_core(request_
>" bad whitespace");
>  return;
>  }
> -
> -if (tmp_field == last_field) {
> -r->status = HTTP_BAD_REQUEST;
> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
> -  "Request header field name was empty");
> -return;
> -}
>  }
>  else /* Using strict RFC7230 parsing */
>  {
> _

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

Sounds great. Reviewing Yann's alternate patch now.


On Jun 28, 2017 06:41, "Yann"  wrote:

> On Wed, Jun 28, 2017 at 11:51 AM, Jim Jagielski  wrote:
> > I would also suggest to reroll: I'll test the reroll on my systems here.
>
> +1
>

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

I'd like to know that there is another binding vote before bothering to
reroll. If the interest disappated faster than expected, that's fine.
Assuming your request was an implicit intent to vote on the requested
reroll.

I thought this bug was more complex, but put all my other concerns aside,
we are looking pretty good according to the test framework. Looks like a
one line patch as described in the bugzilla ticket.

On Jun 27, 2017 12:44, "Jacob Champion"  wrote:

> On 06/27/2017 10:21 AM, William A Rowe Jr wrote:
>
>> If voters would rather that I address https://bz.apache.org/bugzilla
>> /show_bug.cgi?id=61220 and reroll, I'm fine with that.
>>
>
> I think that would be good, since we're planning to make this the Final
> Release.
>
> --Jacob
>

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

On Jun 23, 2017 5:19 PM, "William A Rowe Jr"  wrote:

For your consideration... pre-release candidate tarballs of
Apache legacy httpd 2.2.33 can be found in;

http://httpd.apache.org/dev/dist/

Thanks all who merged the security work in and other fixes.
As we picked end of maintenance Jul 1 '17 - the [discuss]
thread had sufficient time for response - and none of the 2.4
regressions relate to what has been ported to 2.2... it looks
like this is 2.2's final hurrah...

Your votes, please?

+/-1
[ ] Release 2.2.33 as legacy GA


My own conditional +1.

If voters would rather that I address
https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 and reroll, I'm fine
with that.

In any case, votes please. I'll declare the release aborted on the 30th and
the branch EOL on the 1st as originally agreed upon, in the absence of 3
binding reviews.

Re: [VOTE] Release httpd-2.2.33

[William A Rowe Jr]

Thanks Petr, every review and evaluation is appreciated!

On Jun 26, 2017 8:46 AM, "Petr Gajdos"  wrote:

On Fri, Jun 23, 2017 at 05:19:47PM -0500, William A Rowe Jr wrote:
> For your consideration... pre-release candidate tarballs of
> Apache legacy httpd 2.2.33 can be found in;
>
> http://httpd.apache.org/dev/dist/

Not sure if it is valuable info for you; I have run test suite and it
passes, see the attachement.

Petr

RE: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

On Jun 27, 2017 12:08 PM, "Moradhassel, Kavian"  wrote:

Did this discussion result in a decision to provide a fix for the bug in
2.4.26 and plan for a 2.4.27 soon?  I'm wondering if I should be waiting
for a 2.4.27 in the next handful of weeks, or if I should just accept that
2.4.26 has a bug that we need to work around...


We don't generally try to predict our release schedule, when it's baked we
publish a release.

But Jim and Jacob are furiously updating the test framework as you were
asking your question, so I'm guessing the group will be working to release
this fix just as soon as it is agreed upon, within a week or few.

Re: Anonymizing 403 responses [Was: svn commit: r1799731]

[William A Rowe Jr]

On Jun 27, 2017 3:00 AM, "Yann"  wrote:

On Tue, Jun 27, 2017 at 12:49 AM, William A Rowe Jr 
wrote:
> On Mon, Jun 26, 2017 at 5:43 PM, William A Rowe Jr 
wrote:
>> On Mon, Jun 26, 2017 at 5:34 PM, Yann  wrote:
>>
>>> What could be the "security blunders" with 404 vs 403?
>>
>> A 403 says "go away, you are denied". Hopefully modules are smart
>> about that.

It seems that one can create a "regular" file or directory containing
such "reserved" word (by using UNC paths, but I don't know enough
about Windows to say if it's really the case and from which version).
So we (or APR) should be able to determine whether it really exists or
not, and/or its access is truly denied by the OS (or httpd), and
return the correct 4xx no?


No. AIUI pervasive device names cannot be used as regular directory or
filenames at all.

It does exist. ./NULL on Windows is just as much a file as /dev/null is on
Unix.

APR does report this is a CHR file type/device.

The correct result has long been 403 forbidden on any OS.

Ignore Gregg's patch and go back to the underlying complaint. Rather than
forbidden, users are asking in a general scope for security by obscurity,
of advising the user agent that forbidden resources apparently don't exist.

As you pointed out this is not a great solution to bad admin practices.
But, the ask is there, so please ignore "on Windows" and let's consider
what is involved in adding support for a hard declaration of 404, or a late
transition from 403 to 404 (or any response code X to Y, for that matter.)

Re: Anonymizing 403 responses [Was: svn commit: r1799731]

[William A Rowe Jr]

On Mon, Jun 26, 2017 at 5:43 PM, William A Rowe Jr  wrote:
> On Mon, Jun 26, 2017 at 5:34 PM, Yann  wrote:
>
>> What could be the "security blunders" with 404 vs 403?
>
> A 403 says "go away, you are denied". Hopefully modules are smart
> about that.
>
> A 404 says "no such resource". Modules such as mod_speling try to
> interpret what the user typed in an accommodating way, and come up
> with something that aught to be served instead.
>
> In the particular example, /CON (device) might be interpreted as /.conf
> (file). But if the admin/author is attentive, they deny access to .conf and
> the remap attempt fails.

FWIW mod_speling is well-understood to reveal such 'hidden files'.
Even if we fixed the specific case for /con (device) remapping, all
the user would have to do is attempt to access ".con" (no file found)
to discover .conf in that directory, if it isn't prohibited.

I trust that both presenting CHR files as 403 is not an issue, and that
mod_speling's behavior is correct so far as it goes if users choose to
deploy it. But it seems like there should be some deterministic way
to reject non-file or other entities as not-found without other modules
attempting to 'just fix it.'

Re: Anonymizing 403 responses [Was: svn commit: r1799731]

[William A Rowe Jr]

On Mon, Jun 26, 2017 at 5:34 PM, Yann  wrote:
> On Mon, Jun 26, 2017 at 11:51 PM, William A Rowe Jr  
> wrote:
>> On Mon, Jun 26, 2017 at 4:44 PM, William A Rowe Jr  
>> wrote:
>>>
>>> On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith  wrote:
>>>>
>>>> On 6/24/2017 10:02 AM, William A Rowe Jr wrote:
>>>>>
>>>>> On Sat, Jun 24, 2017 at 12:49 AM,   wrote:
>>>
>>>>> While we are at it, why even forking WIN32? If you want to prevent
>>>>> APR_CHR files on Windows (or netware or os2 or...) from being
>>>>> identified, why wouldn't you simply change the behavior across all
>>>>> architectures with a new test case ahead of the != APR_DIR check...
>>>>>
>>>>>  else if (thisinfo.filetype == APR_CHR) {
>>>>>  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
>>>>>"Forbidden: %s points to a char stream 
>>>>> path",
>>>>>r->filename);
>>>>>  return r->status = HTTP_NOT_FOUND;
>>>>>  }
>>>>
>>>> Uh yes, but as shown up front the 404 is what we'd get on Unix and forcing
>>>> it 404 is what I was doing while improperly.
>>>
>>> No no no. Unix has CHR devices!!! You can mount them whereever, by
>>> convention they all live under /dev/. But that doesn't mean they cannot
>>> be found elsewhere. Unix httpd will 403 on these.
>>>
>>> We should consider if it's worthwhile "hiding" CHR references under some
>>> response 404, but ***ONLY*** if we can assert this is a terminal 404, not
>>> a recoverable 404. We don't have such a construct yet in httpd, AFAIK.
>>>
>>>>> Let's please back out that patch entirely and start again by asking
>>>>> the question, do we want to treat CHR file paths as not found rather
>>>>> than forbidden, and does anyone see an opportunity for httpd's
>>>>> core or third party modules to proceed to try to work around that
>>>>> file/path leading to potential security blunders? E.g. mod_speling?
>>
>> So coming back to this core question, what would be the workaround
>> to force a 'final determination' of a 404 NOT FOUND in place of any
>> security-related 403's? E.g. if we trip over a disallowed symlink, 403,
>> if we trip over a CHR file, 403... but admin wants to present a 404
>> instead. This must happen after all modules have looked at the 403
>> and stepped out of the way, as opposed to trying to substitute content
>> in the 404 case.
>
> Why modules couldn't (or shouldn't) recover from such 404s like any other one?
> If mod_speling is doing strange things when substituting what it
> thinks is a typo (like serving hidden/forbidden files) that's
> mod_speling's bug IMHO.

Howso?

> What could be the "security blunders" with 404 vs 403?

A 403 says "go away, you are denied". Hopefully modules are smart
about that.

A 404 says "no such resource". Modules such as mod_speling try to
interpret what the user typed in an accommodating way, and come up
with something that aught to be served instead.

In the general example, /indez.html might be recognized as /index.html.

In the particular example, /CON (device) might be interpreted as /.conf
(file). But if the admin/author is attentive, they deny access to .conf and
the remap attempt fails.

What I'm wondering is whether we should offer an early "Absolute 404"
state that informs modules not to try to recover, or whether we should
offer a late 403->404 anonymization feature?

Anonymizing 403 responses [Was: svn commit: r1799731]

[William A Rowe Jr]

On Mon, Jun 26, 2017 at 4:44 PM, William A Rowe Jr  wrote:
>
> On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith  wrote:
>>
>> On 6/24/2017 10:02 AM, William A Rowe Jr wrote:
>>>
>>> On Sat, Jun 24, 2017 at 12:49 AM,   wrote:
>
>>> While we are at it, why even forking WIN32? If you want to prevent
>>> APR_CHR files on Windows (or netware or os2 or...) from being
>>> identified, why wouldn't you simply change the behavior across all
>>> architectures with a new test case ahead of the != APR_DIR check...
>>>
>>>  else if (thisinfo.filetype == APR_CHR) {
>>>  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
>>>"Forbidden: %s points to a char stream path",
>>>r->filename);
>>>  return r->status = HTTP_NOT_FOUND;
>>>  }
>>
>> Uh yes, but as shown up front the 404 is what we'd get on Unix and forcing
>> it 404 is what I was doing while improperly.
>
> No no no. Unix has CHR devices!!! You can mount them whereever, by
> convention they all live under /dev/. But that doesn't mean they cannot
> be found elsewhere. Unix httpd will 403 on these.
>
> We should consider if it's worthwhile "hiding" CHR references under some
> response 404, but ***ONLY*** if we can assert this is a terminal 404, not
> a recoverable 404. We don't have such a construct yet in httpd, AFAIK.
>
>>> Let's please back out that patch entirely and start again by asking
>>> the question, do we want to treat CHR file paths as not found rather
>>> than forbidden, and does anyone see an opportunity for httpd's
>>> core or third party modules to proceed to try to work around that
>>> file/path leading to potential security blunders? E.g. mod_speling?

So coming back to this core question, what would be the workaround
to force a 'final determination' of a 404 NOT FOUND in place of any
security-related 403's? E.g. if we trip over a disallowed symlink, 403,
if we trip over a CHR file, 403... but admin wants to present a 404
instead. This must happen after all modules have looked at the 403
and stepped out of the way, as opposed to trying to substitute content
in the 404 case.

This seems doable, IMO.

Re: svn commit: r1799731 - in /httpd/httpd/trunk: CHANGES server/request.c

[William A Rowe Jr]

Hi Gregg,

sending publicly while you have a negotiation with your email client :)

On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith  wrote:
>
> On 6/24/2017 10:02 AM, William A Rowe Jr wrote:
>>
>> On Sat, Jun 24, 2017 at 12:49 AM,   wrote:
>>>
>>> Author: gsmith
>>> Date: Sat Jun 24 05:49:45 2017
>>> New Revision: 1799731
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1799731&view=rev
>>> Log:
>>> Send a 404 response like other OSs do instead of 403 on Windows when
>>> a path segment or file requested uses a reserved word so Windows
>>> cannot be fingerprinted. PR55887
>>
>> How does this solve fingerprinting?
>
> Simple Bill, does this 403?
> http://httpd.apache.org/foo/bar/lpt1/test/
> No.
>
> This?
> https://is.kaput.gq/foo/bar/lpt1/test/
> Yes

I didn't ask whether there is a difference. I asked if this patch has
comprehensively avoided fingerprinting. The answer is no for a long
host of reasons, from 8.3 pathnames to mixed case to... and on and
on. It is not worth breaking code I fixed almost 20 years ago to maybe
pretend to accomplish.

>> You should be aware that this code path can be hit a number of times
>> per request, often hundreds for an autoindex listing, etc. You should
>> see a notable rise in cpu.

So this is not altogether correct, I overreacted on this one point. As it
turns out, the file path element has to already fail a REG or DIR check
before we start exercising your code path.

Still, it's inappropriate and incorrect.

>> But why a regex against the URI?!? That's horrible, you are reparsing
>> all those leading bytes we already parsed. Part of the URI may have
>> been alias-mapped away from one resource name to another (or in
>> the htaccess case, mapped into a badly named path.) r->filename
>> is the cumulative name of the *FILE* we are inspecting, not *URI*.
>
> Mainly because I had a problem with r->filename and with r->uri I didn't.
> However, I know the problem I had was not with r->filename but I forgot to
> run back to it.

No worries, but not ready for trunk.

>> Worse still, because seg_name is the actual path component we are
>> now looking at, e.g. from /path/to/lpt1/foo - if we are at the third elt
>> that string becomes the normalized form of lpt1. There was no reason
>> to be reinspecting the earlier path elts throughout the segment walk!
>>
>> But this could all be identified by the APR_CHR ->filetype, no? Sure
>> beats an unnecessarily long string pattern match.
>
> Mainly because I did not know about it and I can't say whether or not I'd
> have known what "a character device" meant though I hope I would have.

Again, no worries, not ready for trunk.

>> While we are at it, why even forking WIN32? If you want to prevent
>> APR_CHR files on Windows (or netware or os2 or...) from being
>> identified, why wouldn't you simply change the behavior across all
>> architectures with a new test case ahead of the != APR_DIR check...
>>
>>  else if (thisinfo.filetype == APR_CHR) {
>>  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
>>"Forbidden: %s points to a char stream
>> path",
>>r->filename);
>>  return r->status = HTTP_NOT_FOUND;
>>  }
>
> Uh yes, but as shown up front the 404 is what we'd get on Unix and forcing
> it 404 is what I was doing while improperly.

No no no. Unix has CHR devices!!! You can mount them whereever, by
convention they all live under /dev/. But that doesn't mean they cannot
be found elsewhere. Unix httpd will 403 on these.

We should consider if it's worthwhile "hiding" CHR references under some
response 404, but ***ONLY*** if we can assert this is a terminal 404, not
a recoverable 404. We don't have such a construct yet in httpd, AFAIK.

> Because I tested and got a 404 instead of a 403 with the numerous
> possibilities I tried.

Sure. And this is a bug how?

>> Let's please back out that patch entirely and start again by asking
>> the question, do we want to treat CHR file paths as not found rather
>> than forbidden, and does anyone see an opportunity for httpd's
>> core or third party modules to proceed to try to work around that
>> file/path leading to potential security blunders? E.g. mod_speling?
>> If we agree that APR_CHR can be 'anonymized' then a generic
>> and fast fix is in order.
>
> I think I've proved it's going to 403 where it won't on Unix. Not I too much
> but many Windows users 

Re: svn commit: r1799375 - /httpd/httpd/trunk/server/util.c

[William A Rowe Jr]

On Mon, Jun 26, 2017 at 3:14 PM, Jacob Champion  wrote:
> On 06/20/2017 11:08 PM, William A Rowe Jr wrote:
>>
>> Sorry but I reraise my objection and veto worthless cpu cycles.
>
> For posterity, can I get a succinct description of your technical
> justification for this veto?

I have several.

 * Wasting CPU cycles for a no-op *which the compiler cannot
   recover from is unacceptable. httpd is coded in C for a reason,
   with all the associated side effects. Any deoptimization as some
   matter of style or as a matter of security (e.g. stack -> alloc) is
   discussed on list and the costs weighed by the group.

 * The test_char.h table is a private-use entity with 256 well-defined
   octets (not utf-8, not char-wise, these are raw bytes). Sometimes,
   and often for some platform, one is wrong, it is simply fixed, and
   the sole consumer, util.c, is corrected.

 * The test_char.h table is private-use and is not exported, not installed
   to httpd target include/, etc. util.c was its sole consumer.

 * mod_log_forensic changed this and started consuming an include
   which was buried under server/ for its own devices. Questionable,
   but still a core module (changes to the core table less likely to be
   caught when reviewing the module, but the toggle is clearly labeled
   FORENSIC, so there's that. Note the module duplicates the entire
   table, but it's forensic/diagnostic so I don't care what such code
   and const static footprints look like.)

 * T_HTTP_TOKEN_STOP declared NUL did not stop a token. That
   is an idiotic assertion. I inverted it. Cursory examination of the code,
   I did not spend enough time studying side-effects of the end-of-string
   behaviors, nor did the many other reviewers, I looked at the immediate
   affected logic. All use of this array and it's value of element NUL are
   exercised in util.c, this is not like it was some obscure external citation.

 * I agree with you the entire thing is unclear because there is no entity
   called a TOKEN_STOP, although there are recognized separators,
   and non-token garbage entities, but the functions implicated never
   bothered to distinguish between any of this. T_HTTP_TOKEN is
   clearer and less ambiguous (and NUL does not belong in that set.)
   I'm about to propose that change and will VOTE DOWN any call
   to backport that change to 2.4, as...

 * This change is mutually agreed to be a no-op, and you've made
   clear the intent was to backport to a stable, maintenance branch
   which should see NO deltas which have no effect. For example,
   whitespace correction is absolutely prohibited on a release branch
   because the svn blame ... comprehension of the changes to the
   code is destroyed by a stupid endeavor to make things look nice.
   When whitespace changes are introduced, it is in order to port
   the minimal, identical changes previously applied to trunk, so that
   a functional patch can be applied cleanly from an svn merge.

So to convince me my veto is unwarranted, you need to basically
convince me that the array elts are too volatile to trust, including the
elt[0], or that we have a long tradition of getting this wrong (I suggest
we don't - this was an exception), that we are unable to maintain the
pairing util.c <> test_char.h. OR that we are about to export test_char.h
to a much less attentive audience as a public export, etc.

Re: [Discuss] Rolling a 'final' 2.2.33 release

[William A Rowe Jr]

That would have been a good fix to include, but the release has been
tagged. If it is voted down on some other defects and we roll 2.2.34, I
would concur. But there is no defined single char header, and x- headers
are always 3+ chars by definition. So I don't look at this one as a
showstopper.

>From here on out, all defect fixes will be up to the end user to patch, I'm
most concerned about getting a release with the full assortment of security
fixes into users's hands reminding them the branch is EOL now, as we close
the 2.2 chapter.

On Jun 25, 2017 4:56 PM, "Mark Blackman"  wrote:

>
> On 14 Jun 2017, at 22:12, William A Rowe Jr  wrote:
>
>
> Thoughts/comments? Patches to hold for before we roll? If I don't hear
> otherwise, and we stick to the simpler alternative, then I'd plan to roll
> these candidates Thursday.
>
>
> Would it be an option to get a fix in for the single-character header bug?
> ( https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 )
>
> If you add
>
> HttpProtocolOptions Unsafe LenientMethods Allow0.9
>
> to a default httpd.conf
>
> single character header lines are rejected with a 400 code.
>
> macmini:httpd-2.2.33 mark$ telnet localhost 8033
> Trying ::1...
> Connected to localhost.
> Escape character is '^]'.
> GET / HTTP/1.1
> Host: foobar
> x: 0
>
> HTTP/1.1 400 Bad Request
> Date: Sun, 25 Jun 2017 21:43:53 GMT
> Server: Apache/2.2.33 (Unix)
> Content-Length: 226
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> 
> 
> 400 Bad Request
> 
> Bad Request
> Your browser sent a request that this server could not understand.
> 
> 
> Connection closed by foreign host.
>
>

Re: svn commit: r1799731 - in /httpd/httpd/trunk: CHANGES server/request.c

[William A Rowe Jr]

On Sat, Jun 24, 2017 at 12:49 AM,   wrote:
> Author: gsmith
> Date: Sat Jun 24 05:49:45 2017
> New Revision: 1799731
>
> URL: http://svn.apache.org/viewvc?rev=1799731&view=rev
> Log:
> Send a 404 response like other OSs do instead of 403 on Windows when
> a path segment or file requested uses a reserved word so Windows
> cannot be fingerprinted. PR55887

How does this solve fingerprinting?

This patch was ill-conceived... -1 as explained below;

> +#ifdef _WIN32
> +/* Windows has a number of reserved words that cannot be used
> + * as a file or directory name so thisinfo.filetype will
> + * always be != APR_DIR. Don't allow us be fingerprinted with
> + * a 403 and instead send a 404 like other OSs would. PR55887
> + */
> +preg = ap_pregcomp(r->pool,
> +  
> "/(aux|con|com[1-9]|lpt[1-9]|nul|prn)"
> +  "($|/|.)", 
> AP_REG_EXTENDED | AP_REG_ICASE);
> +if (ap_regexec(preg, r->uri, 0, NULL, 0) == 0)
> +return r->status = HTTP_NOT_FOUND;
> +#endif

You should be aware that this code path can be hit a number of times
per request, often hundreds for an autoindex listing, etc. You should
see a notable rise in cpu.

As suggested this could be a compile-once and recycle pattern.

But why a regex against the URI?!? That's horrible, you are reparsing
all those leading bytes we already parsed. Part of the URI may have
been alias-mapped away from one resource name to another (or in
the htaccess case, mapped into a badly named path.) r->filename
is the cumulative name of the *FILE* we are inspecting, not *URI*.

Worse still, because seg_name is the actual path component we are
now looking at, e.g. from /path/to/lpt1/foo - if we are at the third elt
that string becomes the normalized form of lpt1. There was no reason
to be reinspecting the earlier path elts throughout the segment walk!

But this could all be identified by the APR_CHR ->filetype, no? Sure
beats an unnecessarily long string pattern match.

While we are at it, why even forking WIN32? If you want to prevent
APR_CHR files on Windows (or netware or os2 or...) from being
identified, why wouldn't you simply change the behavior across all
architectures with a new test case ahead of the != APR_DIR check...

else if (thisinfo.filetype == APR_CHR) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
  "Forbidden: %s points to a char stream path",
  r->filename);
return r->status = HTTP_NOT_FOUND;
}
   else if (thisinfo.filetype != APR_DIR) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
  "Forbidden: %s doesn't point to "
  "a file or directory",
  r->filename);
return r->status = HTTP_FORBIDDEN;
}

As I asked upfront, why is it believed that this solves the win32
issue? It's trivial to check for case folding and that folding will
occur in a manner unique to the Windows implementation of the
NTFS filesystem. You would need to modify the following code
to force case mismatches to a 404 result to try to convince anyone
that the server is running on unix, non-samba;

if ((thisinfo.valid & APR_FINFO_NAME)
&& strcmp(seg_name, thisinfo.name)) {
/* TODO: provide users an option that an internal/external
 * redirect is required here?  We need to walk the URI and
 * filename in tandem to properly correlate these.
 */
strcpy(seg_name, thisinfo.name);
filename_len = strlen(r->filename);
}

More to the point, the actual TCP traffic itself is subject to all sorts
of inferences if it can be observed (and that this isn't a proxied box
behind the firewall.)

Let's please back out that patch entirely and start again by asking
the question, do we want to treat CHR file paths as not found rather
than forbidden, and does anyone see an opportunity for httpd's
core or third party modules to proceed to try to work around that
file/path leading to potential security blunders? E.g. mod_speling?
If we agree that APR_CHR can be 'anonymized' then a generic
and fast fix is in order.

p.s. Next time we try to deoptimize the code this badly, let's add a
config option so the admin chooses to spend such extra cycles?

[VOTE] Release httpd-2.2.33

[William A Rowe Jr]

For your consideration... pre-release candidate tarballs of
Apache legacy httpd 2.2.33 can be found in;

http://httpd.apache.org/dev/dist/

Thanks all who merged the security work in and other fixes.
As we picked end of maintenance Jul 1 '17 - the [discuss]
thread had sufficient time for response - and none of the 2.4
regressions relate to what has been ported to 2.2... it looks
like this is 2.2's final hurrah...

Your votes, please?

+/-1
[ ] Release 2.2.33 as legacy GA


Note .tar contains apr 1.5.2, apr-util 1.5.4 while -win32-src.zip
also contains apr-iconv 1.2.1, in keeping with 2.2 conventions.
New language in INSTALLING and additional language in the
Announcement warns users away from the also bundled PCRE
and Expat sources, in favor of current releases.

Re: buildbot failure in on httpd-trunk

[William A Rowe Jr]

If two commits occur in a short enough period of time, the datestamp of the
newly refreshed source may be earlier than the .o generated by the first
update.

On Jun 21, 2017 11:06, "Jacob Champion"  wrote:

> On 06/21/2017 09:00 AM, build...@apache.org wrote:
>
>> The Buildbot has detected a new failure on builder httpd-trunk while
>> building . Full details are available at:
>>  https://ci.apache.org/builders/httpd-trunk/builds/682
>>
>
> It works! \o/
>
> Now to figure out why it took until the clean rebuild to catch, instead of
> the immediate build after the commit.
>
> --Jacob
>

Re: buildbot failure in on httpd-trunk

[William A Rowe Jr]

mod_proxy_balancer.c: In function 'balancer_handler':
mod_proxy_balancer.c:1144:25: error: 'HCHECK_WATHCHDOG_INTERVAL'
undeclared (first use in this function)
 if (ival >= HCHECK_WATHCHDOG_INTERVAL) {
 ^
mod_proxy_balancer.c:1144:25: note: each undeclared identifier is
reported only once for each function it appears in


On Jun 21, 2017 11:00,  wrote:

> The Buildbot has detected a new failure on builder httpd-trunk while
> building . Full details are available at:
> https://ci.apache.org/builders/httpd-trunk/builds/682
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: bb_slave6_ubuntu
>
> Build Reason: The Nightly scheduler named 'httpd-trunk-nightly-clean'
> triggered this build
> Build Source Stamp: [branch httpd/httpd/trunk] HEAD
> Blamelist:
>
> BUILD FAILED: failed compile
>
> Sincerely,
>  -The Buildbot
>
>
>
>