Re: Define variable in modules

[William A Rowe Jr]

It sounds like the desired change is , but there
isn't a baked-in module revision field, not even a module release date that
would be helpful here, so that isn't promising. IfDefine is a solution.

Wouldn't  solve this once and for all,
for many use cases? Ship a patch for folks who want to rely on this with any
rebuilt httpd 2.4.older?


On Fri, Oct 21, 2022 at 9:10 AM Nick Gearls  wrote:
>
> Technically, it would work, and I actually did it in my own modules.
> But I'm afraid some people (at ModSecurity or in other modules) won't accept 
> to misuse a feature :-(
>
> On 20-10-2022 20:35, Christophe JAILLET wrote:
>
> Le 20/10/2022 à 15:55, Nick Gearls a écrit :
>
> Hello,
>
> It would sometimes be very handy to be able to define a variable (like -D on 
> command-line or "Define xxx" in the config) inside a module.
> This would, for instance, allow to have a config file based on a define from 
> the module, knowing if the new syntax is known or not, etc.
>
> Concrete example: in mod_security2, they introduced a new "collection".
> If you use this collection in an old version, it's a syntax error.
> If mod_security2 defines the variable "support_new_collection" (OK, very bad 
> name obviously), then we can enclose the rule using a " support_new_collection>.
>
> Would it be possible to export a function to define such a variable?
>
> Thanks
>
> Hi,
>
> Maybe this would not be super-clean, but the module could define some 
> (useless) directives (i.e. MOD_SEC2_HAS_NEW_COLLECTION_SUPPORT) and config 
> files could be tweaked with .
>
> This should work as-is without any new code.
> Does it match your use-case?
>
> CJ
>
>

Re: --with-pcre Path Error configuring Apache 2.4.53-.54

[William A Rowe Jr]

There is an alternate solution for 2.4.x that is simpler for me to offer.

it could be argued that an abandoned project, deprecated in 2015, and
entirely abandoned effective June 2021, is only supported with an explicit
path to the pcre-config file, and that only pcre2-config would ever be
searched for in future 2.4.x releases, whether we observe --with-pcre
or establish a new --with-pcre2 config flag. It might not be a bad idea
at this point, since there is no indication of a future httpd major or minor
version bump, given the fierce resistance.



On Fri, Oct 21, 2022 at 5:18 PM William A Rowe Jr  wrote:
>
> The error below is acknowledged, and I worked out how it escaped my radar
> (when pcre2-config exists, the current logic tolerates a broken
> --with-pcre=/path,
> finds the system pcre2-config or pcre-config, and if another dependency picks
> the same path, the "desired" pcre is used and httpd assumes it is the version
> of the system located -config file.)
>
> I'd like to spend a moment setting fresh and realistic expectations of
> the correct
> behavior, and start by proposing to add a new --with-pcre2 to httpd 2.4.x. 
> These
> two flags would interact as follows;
>
> --with-pcre2 (Default) --with-pcre (Default)
> Search the system path for pcre2-config, then for legacy pcre-config scripts
>
> --with-pcre2 (Default) --without-pcre
> Search the system path for ONLY pcre2-config script
>
> --without-pcre2 --with-pcre (Default)
> Search the system path for ONLY legacy pcre-config script
>
> --without-pcre2 --without-pcre
> Absolute failure to configure
>
> --with-pcre2 (Default) --with-pcre=/path
> Search only /path-to-explicit-config, /path/bin/pcre2-config,
> /path/pcre2-config,
> /path/bin/pcre-config, and /path/pcre-config in that order.
> Will not fall back from explicit path to system path.
>
> --with-pcre2=/path --without-pcre
> *or*
> --with-pcre2=/path --with-pcre (Default)
> Search only /path-to-explicit-config, /path/bin/pcre2-config, and
> /path/pcre2-config
> Will not fall back from explicit path to system path.
>
> --without-pcre2 --with-pcre=/path
> Search only /path-to-explicit-config, /path/bin/pcre-config, and
> /path/pcre-config
> (pre-2.4.53 behavior; however no longer falls back from explicit path
> to system path.)
>
> --with-pcre2=/path --with-pcre=/path
> Absolute failure to configure, can't have both.
>
> I need to determine if we can distinguish between default and explicit
> specified --with toggles. If so, then we can handle...
>
> --with-pcre2 (Explicit) --with-pcre (Default)
> Search the system path for ONLY pcre2-config scripts.
>
> --with-pcre2=/path --with-pcre (Explicit)
> *or*
> --with-pcre2 (Explicit) --with-pcre=/path
> *or*
> --with-pcre2 (Explicit) --with-pcre (Explicit)
> Absolute failure to configure, can't have both.
>
> I'd propose if this is accepted after 2.4.next release feedback, that
> all legacy pcre 8.x and early support is ripped out, and honor only the
> --with-pcre2[=path] syntax and forcefully reject the --with-pcre option.
> The suggestions above should provide a mostly painless transition
> to move from 2.4.next to subsequent releases.
>
> Thoughts/comments/objections?
>
> Bill
>
> On Mon, Apr 25, 2022 at 5:59 AM Ruediger Pluem  wrote:
> >
> > See https://bz.apache.org/bugzilla/show_bug.cgi?id=66000
> >
> > On 4/25/22 11:16 AM, Ganeshprasad MS wrote:
> > > We have downloaded the Apache HTTPD source httpd-2.4.53.tar.gz 
> > > <https://dlcdn.apache.org/httpd/httpd-2.4.53.tar.gz> from Apache
> > > software foundation and trying to compile/build the Apache binaries, but 
> > > we are facing the below error while configuring the
> > > Apache HTTPD.
>
> > > Options: --prefix 
> > > /remote/users/gms/2.4.53/apache-pack/build/PKL-AWS-2.4.53.0/Release 
> > > --enable-proxy --enable-proxy-ajp
> > > --enable-proxy-balancer --enable-proxy-http --enable-rewrite 
> > > --enable-info --enable-headers --enable-expires --enable-deflate
> > > --enable-ssl 
> > > --with-ssl=/remote/users/gms/2.4.53/apache-pack/build/PKL-AWS-2.4.53.0/Release
> > > --with-pcre=/remote/users/gms/2.4.53/apache-pack/build/pcre 
> > > --with-apr=/remote/users/gms/2.4.53/apache-pack/build/apr
> > > --with-apr-util=/remote/users/gms/2.4.53/apache-pack/build/apr-util 
> > > --with-crypto
>
> > > checking for -pcre2-config... no
> > > checking for -pcre-config... no
> > > checking for pcre2-config... no
> > > checking for pcre-config... pcre-config
> > > configure: error: Did not find working script at pcre-config

Re: --with-pcre Path Error configuring Apache 2.4.53-.54

[William A Rowe Jr]

The error below is acknowledged, and I worked out how it escaped my radar
(when pcre2-config exists, the current logic tolerates a broken
--with-pcre=/path,
finds the system pcre2-config or pcre-config, and if another dependency picks
the same path, the "desired" pcre is used and httpd assumes it is the version
of the system located -config file.)

I'd like to spend a moment setting fresh and realistic expectations of
the correct
behavior, and start by proposing to add a new --with-pcre2 to httpd 2.4.x. These
two flags would interact as follows;

--with-pcre2 (Default) --with-pcre (Default)
Search the system path for pcre2-config, then for legacy pcre-config scripts

--with-pcre2 (Default) --without-pcre
Search the system path for ONLY pcre2-config script

--without-pcre2 --with-pcre (Default)
Search the system path for ONLY legacy pcre-config script

--without-pcre2 --without-pcre
Absolute failure to configure

--with-pcre2 (Default) --with-pcre=/path
Search only /path-to-explicit-config, /path/bin/pcre2-config,
/path/pcre2-config,
/path/bin/pcre-config, and /path/pcre-config in that order.
Will not fall back from explicit path to system path.

--with-pcre2=/path --without-pcre
*or*
--with-pcre2=/path --with-pcre (Default)
Search only /path-to-explicit-config, /path/bin/pcre2-config, and
/path/pcre2-config
Will not fall back from explicit path to system path.

--without-pcre2 --with-pcre=/path
Search only /path-to-explicit-config, /path/bin/pcre-config, and
/path/pcre-config
(pre-2.4.53 behavior; however no longer falls back from explicit path
to system path.)

--with-pcre2=/path --with-pcre=/path
Absolute failure to configure, can't have both.

I need to determine if we can distinguish between default and explicit
specified --with toggles. If so, then we can handle...

--with-pcre2 (Explicit) --with-pcre (Default)
Search the system path for ONLY pcre2-config scripts.

--with-pcre2=/path --with-pcre (Explicit)
*or*
--with-pcre2 (Explicit) --with-pcre=/path
*or*
--with-pcre2 (Explicit) --with-pcre (Explicit)
Absolute failure to configure, can't have both.

I'd propose if this is accepted after 2.4.next release feedback, that
all legacy pcre 8.x and early support is ripped out, and honor only the
--with-pcre2[=path] syntax and forcefully reject the --with-pcre option.
The suggestions above should provide a mostly painless transition
to move from 2.4.next to subsequent releases.

Thoughts/comments/objections?

Bill

On Mon, Apr 25, 2022 at 5:59 AM Ruediger Pluem  wrote:
>
> See https://bz.apache.org/bugzilla/show_bug.cgi?id=66000
>
> On 4/25/22 11:16 AM, Ganeshprasad MS wrote:
> > We have downloaded the Apache HTTPD source httpd-2.4.53.tar.gz 
> >  from Apache
> > software foundation and trying to compile/build the Apache binaries, but we 
> > are facing the below error while configuring the
> > Apache HTTPD.

> > Options: --prefix 
> > /remote/users/gms/2.4.53/apache-pack/build/PKL-AWS-2.4.53.0/Release 
> > --enable-proxy --enable-proxy-ajp
> > --enable-proxy-balancer --enable-proxy-http --enable-rewrite --enable-info 
> > --enable-headers --enable-expires --enable-deflate
> > --enable-ssl 
> > --with-ssl=/remote/users/gms/2.4.53/apache-pack/build/PKL-AWS-2.4.53.0/Release
> > --with-pcre=/remote/users/gms/2.4.53/apache-pack/build/pcre 
> > --with-apr=/remote/users/gms/2.4.53/apache-pack/build/apr
> > --with-apr-util=/remote/users/gms/2.4.53/apache-pack/build/apr-util 
> > --with-crypto

> > checking for -pcre2-config... no
> > checking for -pcre-config... no
> > checking for pcre2-config... no
> > checking for pcre-config... pcre-config
> > configure: error: Did not find working script at pcre-config

Re: svn commit: r1898399 - in /httpd/httpd/branches/2.4.x: ./ CHANGES CMakeLists.txt STATUS configure.in server/util_pcre.c

[William A Rowe Jr]

On Thu, Feb 24, 2022 at 4:18 PM  wrote:
>
> Author: wrowe
> Date: Thu Feb 24 22:18:42 2022
> New Revision: 1898399
>
> URL: http://svn.apache.org/viewvc?rev=1898399=rev
> Log:
> Replace PCRE with PCRE2 where it is available
>
>*) Support PCRE2 with buffers reuse through Thread Local Storage.
>   trunk patches:
>   2.4.x patches:
>   https://github.com/apache/httpd/pull/289.diff
>   (PR: https://github.com/apache/httpd/pull/289)
> - +1: ylavic, rpluem, covener, steffenal
> + +1: ylavic, rpluem, covener, steffenal, wrowe
>   ylavic: This backport proposal inludes the PCRE2 backport already 
> accepted,
>   we can apply this one instead or the original one first and then
>   this one (I'd have to rebase the github PR first).

All my testing this week was against PR289 rollup, so it should just
be a matter of doing a merge origin/trunk. I did want to keep the
svn:mergeinfo sync'ed, so I'd merged using the individual commits
after comparing that to trunk.

I noticed we test for PCRE_DUPNAME which is rather silly now,
since ./configure rejects it, and anything even approaching rev 6.6
(the last version that didn't include it) would be incredibly unwise.
We don't use any HAVE_PCRE_DUPNAME macro, so that whole
test could clearly be moved back up to the revision test, it probably
makes sense to reject anything below the 8.x series in the first place.

Re: opinion poll, stale issues

[William A Rowe Jr]

That's not entirely fair...

We have done this periodically, by spamming the bugzilla entries with
"please review under a current version and report back."

Hearing no response after a month, it's trivial to close them for more
info needed. Many aren't applicable to the current revision.

The reporters who want to be heard will respond, and that will
percolate the interesting bugs from the configuration mistakes and
other common confusion points.

Few projects of this scope ever get to inbox 0 state, so a ping to
ensure it is a valid report and draw attention to the most significant
defects is appropriate, I and several others have done this exercise
many times, clearing as many as 1,000 issues or so over the course of
a month or two. But a completely automated process simply closing them
would be considered rude, unless the reporter themself can reopen them
(and the closure message should state that.)

On Mon, Feb 21, 2022 at 3:13 AM Stefan Eissing  wrote:
>
> Thanks all who participated. Almost all of you seem to be happy with the way 
> things are. I rest my case. 
>
> Kind Regards,
> Stefan
>
> > Am 19.02.2022 um 23:59 schrieb Rich Bowen :
> >
> > Speaking only for the docs bugs, I have recently looked through them, and 
> > while many of them are in the "older than a year" basket, almost all of 
> > them are still valid - just we haven't had time to address them yet. It 
> > would be a shame to lose this information, as it's what I pick away at when 
> > I have spare moments now and then.
> >
> > --Rich
> >
> > On 2/16/22 04:32, Stefan Eissing wrote:
> >> How about we close stale issues on our bugzilla after a year without 
> >> changes with
> >> WONTFIX
> >> We are sorry, but no one found the interest/time to work on this.
> >> ideally as an automated job somewhere?
> >> Kind Regards,
> >> Stefan
>

Re: TLS neverbleed design

[William A Rowe Jr]

Considering this from the most extreme example, a hosting service
where co-parties to using the server container are in contention to
steal one anothers' identities, it seems the right answer is...

Entirely isolate the network transport to the specific physical or
SNI-based vhost in a distinct process that knows of only one host key.
It transports no other party's traffic and has no information of any
other credentials.

This can be a pooled resource, where busy hosts end up needing several
threads (marginally more than the number of NICs, depending), but
httpd can simply launch and manage the to-be-secured traffic through a
single pipe for control. af_unix pipes can even pass per-request
socket fd's to that arbiter for single transaction (connection)
traffic.

Anything short of that really isn't isolation. I wouldn't worry about
one process for all the keys vs a process for all the transaction
handling, that's what fcgi is for.

Cheers,

Bill

On Fri, Jan 7, 2022 at 4:35 AM Stefan Eissing  wrote:
>
> A nice new year to everyone!
>
> I was looking at the design of https://github.com/h2o/neverbleed which
> - loads TLS private keys in a separate process
> - creates EVP_PKEY instances that in the sign callback call into the
>   separate process to create the TLS handshake signature
>
> This is surprisingly simple. With a little overhead, it keeps the keys
> in a separate address space, inaccessible to any exploits in the traffic
> serving workers.
>
> I wonder if it is worthwhile to add something similar to our server.
>
> Kind Regards,
> Stefan

Re: svn commit: r1897240 - in /httpd/httpd/trunk/server: main.c util_pcre.c

[William A Rowe Jr]

On Thu, Jan 20, 2022 at 10:33 AM Yann Ylavic  wrote:
>
> On Thu, Jan 20, 2022 at 3:53 PM William A Rowe Jr  wrote:
> >
> > pcre1 is very dangerous, on stack. pcre2 is highly cautioned against
> > using stack for
> > its arrays, by its author. We should heed the advice.
> Not sure if I can do that with PCRE2 if it always
> --no-recurse-on-stack, probably if pcre2_malloc/free are still
> override-able but I didn't look into it yet (until then I'll keep
> using PCRE1..).

To reiterate; PCRE1 is EOL and irreparable from the security
reports which the author has received and cannot share, so it
is very unwise, end of statement.

That's why PCRE2 got written.

Cheers,

Bill

Re: svn commit: r1897240 - in /httpd/httpd/trunk/server: main.c util_pcre.c

[William A Rowe Jr]

On Thu, Jan 20, 2022 at 5:09 AM  wrote:
>
> Author: ylavic
> Date: Thu Jan 20 11:09:34 2022
> New Revision: 1897240
>
> URL: http://svn.apache.org/viewvc?rev=1897240=rev
> Log:
> ap_regex: Use Thread Local Storage (if efficient) to avoid allocations.
>
> PCRE2 wants an opaque context by providing the API to allocate and free it, so
> to minimize these calls we maintain one opaque context per thread (in Thread
> Local Storage, TLS) grown as needed, and while at it we do the same for PCRE1
> ints vectors. Note that this requires a fast TLS mechanism to be worth it,
> which is the case of apr_thread_data_get/set() from/to apr_thread_current()
> when APR_HAS_THREAD_LOCAL; otherwise we'll do the allocation and freeing for
> each ap_regexec().
>
> The small stack vector is used for PCRE1 && !APR_HAS_THREAD_LOCAL only now.

It's good to keep iterating on this, for now, but when I wrote the
patch both pcre1 & pcre2
were supported by an author, if not a whole community.

I don't believe the project can or should ship support for httpd
2.6/3.0/next with support
for a dead library. But it's better not to rip it out just yet.

pcre1 is very dangerous, on stack. pcre2 is highly cautioned against
using stack for
its arrays, by its author. We should heed the advice.

And I'm not a voting participant so take my observations, with both
grains of salt.

Cheers,

Bill

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

[William A Rowe Jr]

On Wed, Jan 19, 2022 at 2:02 AM Ruediger Pluem  wrote:
>
> On 1/18/22 11:03 PM, William A Rowe Jr wrote:
> > On Tue, Jan 18, 2022 at 2:20 PM Ruediger Pluem  wrote:
> >>
> >> On 1/18/22 8:54 PM, Yann Ylavic wrote:
> >>> On Tue, Jan 18, 2022 at 7:48 PM William A Rowe Jr  
> >>> wrote:
> >>>>
> >>>> Hi Joe, Yann and company,
> >>>>
> >>>> please consider this, we will not build against PCRE2 without 
> >>>> pcre2-config
> >>>> installed from a pcre2-dev package. We find PCRE1 with pcre-config and 
> >>>> link
> >>>> to it, no hassle.
> >>>
> >>> My concern is about the defaut, what happens if no --with-pcre or
> >>> --with-pcre=yes is specified?
> >>>
> >>>>
> >>>> If someone went to the trouble of installing pcre2, wouldn't we want
> >>>> to pick that
> >>>> up, even across a patch release?
> >>>
> >>> I think that a lot of systems have both installed (including the -dev
> >>> packages for building) since pcre2 is the only one supported by some
> >>> projects now and at least httpd requires pcre1 (until the next
> >>> release) so it's likely there too already.
> >>> I haven't looked at the configure part of the patch yet, it's possible
> >>> that your proposed backport already picks up pcre1 when both are
> >>> available (which looks the most reasonable to me for 2.4.x), I'm just
> >>> lazily asking..
> >>
> >> I think the default is pcre2:
> >>
> >> https://gist.github.com/wrowe/73f655d13bbe0f12030aa4557e804d8a#file-httpd-2-4-x-pcre2-10-x-patch-L97-L99
> >>
> >> Regards
> >>
> >> Rüdiger
> >
> > You are right - pcre2-10.x is the new default of the proposed patch
> > and the behavior of trunk.
> >
> > I do understand that RHEL, Ubuntu, all the other packagers are
> > applying patches on patches even of this abandoned branch.
> >
> > However the author advises us, it's a bad idea to play with pcre
> > arrays on stack. The author advises us that there are known
> > vulnerabilities (known to him) that cannot be fixed on the 8.x branch,
> > owing to the underlying design. Whether we care, since the flaws are
> > mostly in the expressions under the control of the admin, and not the
> > untrusted input against the expressions, I don't know.
>
> Ok. This is a good point. This makes me think of the following:
>
> 1. We should switch the default to pcre2 latest when we have found a solution 
> with pcre2 that
>avoids the constant memory allocations on heap on each regex execution 
> (see discussion elsewhere on the thread).
> 2. We should clearly state in the CHANGES entry that we switch the default to 
> pcre2 once we do as currently it states:
>
>*) Support pcre2 (10.x) library in place of the now end-of-life pcre (8.x)
>   for regular expression evaluation. This depends on locating 
> pcre2-config.
>   [William Rowe, Petr Pisar , Rainer Jung]
>
>Which suggests to the user that it *can* use pcre2 if pcre2-config is 
> present, but not it *will* use it if pcre2-config
>is present.

The key question, do we do this on stack? The library author wisely advises
against our doing this again to avoid stack smashing vectors, and rightly so.
This is the point in time to avoid high-risk coding practices.

So if someone (not me, not this month, too buried) wants to do this... even to
take the suggestion of _ex() functions which have a threadkey tied to the passed
single-threaded pool, I'd be in favor, and it's worth delaying a pcre2-10.x and
openssl 3.0.0 compatible release for just a week or few to work that in.

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

[William A Rowe Jr]

On Tue, Jan 18, 2022 at 2:20 PM Ruediger Pluem  wrote:
>
> On 1/18/22 8:54 PM, Yann Ylavic wrote:
> > On Tue, Jan 18, 2022 at 7:48 PM William A Rowe Jr  
> > wrote:
> >>
> >> Hi Joe, Yann and company,
> >>
> >> please consider this, we will not build against PCRE2 without pcre2-config
> >> installed from a pcre2-dev package. We find PCRE1 with pcre-config and link
> >> to it, no hassle.
> >
> > My concern is about the defaut, what happens if no --with-pcre or
> > --with-pcre=yes is specified?
> >
> >>
> >> If someone went to the trouble of installing pcre2, wouldn't we want
> >> to pick that
> >> up, even across a patch release?
> >
> > I think that a lot of systems have both installed (including the -dev
> > packages for building) since pcre2 is the only one supported by some
> > projects now and at least httpd requires pcre1 (until the next
> > release) so it's likely there too already.
> > I haven't looked at the configure part of the patch yet, it's possible
> > that your proposed backport already picks up pcre1 when both are
> > available (which looks the most reasonable to me for 2.4.x), I'm just
> > lazily asking..
>
> I think the default is pcre2:
>
> https://gist.github.com/wrowe/73f655d13bbe0f12030aa4557e804d8a#file-httpd-2-4-x-pcre2-10-x-patch-L97-L99
>
> Regards
>
> Rüdiger

You are right - pcre2-10.x is the new default of the proposed patch
and the behavior of trunk.

I do understand that RHEL, Ubuntu, all the other packagers are
applying patches on patches even of this abandoned branch.

However the author advises us, it's a bad idea to play with pcre
arrays on stack. The author advises us that there are known
vulnerabilities (known to him) that cannot be fixed on the 8.x branch,
owing to the underlying design. Whether we care, since the flaws are
mostly in the expressions under the control of the admin, and not the
untrusted input against the expressions, I don't know.

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

[William A Rowe Jr]

On Mon, Jan 17, 2022 at 6:38 PM Yann Ylavic  wrote:
>
> On Mon, Jan 17, 2022 at 4:05 PM Joe Orton  wrote:
> >
> > For 2.4.x I would argue it's better to keep a preference for 8.x over
> > 10.x so that users aren't switched from one to the other across an
> > upgrade - with some new performance trade-off we know about - without
> > changing the environment/configure line?
>
> +1, we should try to find PCRE1 first in 2.4.x and fall back to PCRE2
> only if PCRE1 is not there.

Hi Joe, Yann and company,

please consider this, we will not build against PCRE2 without pcre2-config
installed from a pcre2-dev package. We find PCRE1 with pcre-config and link
to it, no hassle.

If someone went to the trouble of installing pcre2, wouldn't we want
to pick that
up, even across a patch release?

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

[William A Rowe Jr]

On Mon, Jan 17, 2022, 09:37 Ruediger Pluem  wrote:

>
>
> On 1/17/22 4:05 PM, Joe Orton wrote:
> > On Sun, Jan 16, 2022 at 03:35:15PM -0600, William A Rowe Jr wrote:
> >> 4 day ago, you all saw this. 6 years ago, you all started using this on
> trunk.
> >>
> >> Don't know what I can to do help this along and honor the library
> >> author's wishes for all of us to walk away from the dead fork, and use
> >> the maintained fork. It's whatever it is, I'm out of here and removing
> >> the backport application branch, whoever 3rd upvotes this be prepared
> >> to apply this for us all, thanks.
> >
> > I'm fine with PCRE 10.x as a trunk/2.5 feature.  PCRE upstream have
> > maintained 8.x better than e.g. zlib upstream have done in recent years
> > (last zlib release in 2017).  So I don't find the fact it's considered
> > EOL upstream presents any particular urgency, it's still supported
> > downstream on platforms people deploy to.
> >
> > For 2.4.x I would argue it's better to keep a preference for 8.x over
> > 10.x so that users aren't switched from one to the other across an
> > upgrade - with some new performance trade-off we know about - without
> > changing the environment/configure line?
>
> Sounds sensible for Linux to keep the default to 8.x if found where people
> can expect their distribution to maintain stuff provided that the
> distribution is still maintained.
> I am not so sure for other platforms especially Windows where I guess that
> people get stuff
> more often directly from upstream.
>

Sensible? Did you read the memo at pcre.org? There will be no more
evaluations of security risks on the abandoned fork and we were told this
back in May 2021.

Do you still have the same posture? Some of us spent the last 5 years
arguing for httpd.next, and I resigned over it. Your call, you are PMC and
I choose not to be.

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

[William A Rowe Jr]

Ixney on the alloca. That's the entire point of not moving array
allocations to the stack, because the author won't take responsibility for
potential underflows and overflows. Stack is the wrong place for these bits



On Mon, Jan 17, 2022, 06:38 Eric Covener  wrote:

> On Mon, Jan 17, 2022 at 7:28 AM Ruediger Pluem  wrote:
> >
> >
> >
> > On 1/16/22 10:35 PM, William A Rowe Jr wrote:
> > > 4 day ago, you all saw this. 6 years ago, you all started using this
> on trunk.
> > >
> > > Don't know what I can to do help this along and honor the library
> > > author's wishes for
> > > all of us to walk away from the dead fork, and use the maintained
> > > fork. It's whatever
> > > it is, I'm out of here and removing the backport application branch,
> > > whoever 3rd upvotes
> > > this be prepared to apply this for us all, thanks.
> >
> > With regards to the de-optimization / stack usage probably stupid
> question:
> > Can't we use the TLS features that several compilers offer?
> > e.g. see at the end of the page at
> https://stackoverflow.com/questions/18298280/how-to-declare-a-variable-as-thread-local-portably
> >
> > If we have no thread_local we could fall back to the current unoptimized
> implementation?
>
> I more identified with Joe's comment, if we had an _ex version we
> could pass pools for our own usage.
> If some other heavy regex hitter third-party module finds an issue
> (like mod_security) it might degrade a little bit but they can always
> take advantage of it too.
>
> Also, what about alloca()?
>
> Trivia but I should add that in an integration between two third-party
> mods I recently ripped out apr_threadkey stuff due to a crash after
> some OS updates that nobody can explain. Fortunately the problematic
> API had been extended with userdata and it was no longer absolutely
> necessary. It was our only use of these API's so I was glad to
> simplify and just remove them and move on.
> Net, I would be hesitant to introduce something too new.
>

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

[William A Rowe Jr]

4 day ago, you all saw this. 6 years ago, you all started using this on trunk.

Don't know what I can to do help this along and honor the library
author's wishes for
all of us to walk away from the dead fork, and use the maintained
fork. It's whatever
it is, I'm out of here and removing the backport application branch,
whoever 3rd upvotes
this be prepared to apply this for us all, thanks.


On Wed, Jan 12, 2022 at 9:28 PM  wrote:
>
> Author: wrowe
> Date: Thu Jan 13 03:28:31 2022
> New Revision: 1896976
>
> URL: http://svn.apache.org/viewvc?rev=1896976=rev
> Log:
> Propose pcre2 support for backport
>
> 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=1896976=1896975=1896976=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Thu Jan 13 03:28:31 2022
> @@ -150,6 +150,35 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
>  PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>[ New proposals should be added at the end of the list ]
>
> +  *) Support PCRE2 (10.x) in place of PCRE (8.x).
> + Submitted by: wrowe, Petr Pisar [ppisar redhat.com], rjung
> + trunk patches:
> + http://svn.apache.org/r1773454
> + http://svn.apache.org/r1773741
> + http://svn.apache.org/r1773742
> + http://svn.apache.org/r1773839
> + http://svn.apache.org/r1773870
> + http://svn.apache.org/r1773882
> + http://svn.apache.org/r1814662
> + http://svn.apache.org/r1881478
> + summarized/conflicts resolved:
> + https://gist.github.com/wrowe/73f655d13bbe0f12030aa4557e804d8a
> + +1: wrowe
> + wrowe notes that the current code drops optimizations, owing to the fact
> + that the ovector is a required allocation and is no longer allocated on
> + the stack, by design.  The correct fix is an apr userdata allocation on
> + the appropriate pool, which would be thread-safe, but the actual API of
> + ap_regexec[_len]() offers us no pool and isn't suitable for httpd-2.4.x.
> + At this time, PCRE 8.45 is EOL and will not receive security updates,
> + and taking ovector and other arrays off the stack was in direct reaction
> + to the patterns of abuse of previous pcre exploits. So this patch 
> doesn't
> + wait for httpd-2.4 to be retired, it will need to be adopted without the
> + existing optimiation.
> + jorton: Adding ap_pregexec/_len which pass a pool would also work
> + for internal users of this api; not sure if performance
> + impact is significant from using malloc here.
> +
> +
>  PATCHES/ISSUES THAT ARE BEING WORKED
>[ New entries should be added at the START of the list ]
>
> @@ -256,28 +285,6 @@ PATCHES/ISSUES THAT ARE BEING WORKED
>   make it nonblocking (by default)?
>  jim: Non-blocking seems the best way to handle...
>
> -   * Support PCRE2 (10.x) in place of PCRE (8.x).
> - Submitted by: wrowe, Petr Pisar [ppisar redhat.com]
> - trunk patches:
> - http://svn.apache.org/r1773454
> - http://svn.apache.org/r1773741
> - http://svn.apache.org/r1773742
> - http://svn.apache.org/r1773839
> - http://svn.apache.org/r1773870
> - http://svn.apache.org/r1773882
> - wrowe notes that the current code is too inefficient, owing to the fact
> - that the ovector is a required allocation and is no longer allocated on
> - the stack, by design. The correct fix is an apr userdata allocation on
> - the appropriate pool, which would be thread-safe, but the actual API of
> - ap_regexec[_len]() offers us no pool. We cannot associate that pool with
> - the ap_regex_t, because a single regex may be used by many threads in
> - parallel and is not thread-safe beyond initialization.
> - So the only fix allowing us to use PCRE 10 in httpd 2.4 would be to 
> write
> - this as a thread safe storage buffer for the majority of cases (<10 
> $args)
> - and we don't have a portable tls mechanism to do so.
> - jorton: Adding ap_pregexec/_len which pass a pool would also work
> - for internal users of this api; not sure if performance
> - impact is significant from using malloc here.
>
>  PATCHES/ISSUES THAT ARE STALLED
>
>
>

Re: httpd test framework svn repo borked?

[William A Rowe Jr]

On Fri, Jan 14, 2022 at 4:08 AM Stefan Sperling  wrote:
>
> On Thu, Jan 13, 2022 at 07:17:27PM -0600, William A Rowe Jr wrote:
> > Thanks Stefan, it's attempting [locally] to replace a file, which was
> > just created during the
> > checkout (which might even be open).
>
> Hmm. I assume SVN would close such files based on APR pool lifetime.
>
> Handling of the pristine installation step has been changed in SVN trunk:
> https://svn.apache.org/r1886490
> In particular:
> """
> On Windows, it uses the existing mechanism of installing the files
> by handle, without having to reopen them.
> """

As indicated, this is in the ubuntu 18.04 SFU on windows, the msys2-64
current distribution, as well as Windows "native". Very consistent.

> If you are running 1.14 or an older release, perhaps try a client
> built from trunk to see if this issue has already been fixed for
> a future SVN 1.15 release?

I'm happy to have a look next week.

> > So it looks like some hash
> > collision or other
> > duplication issue where there are two attempts to emplace the same
> > hash svn-base image,
> > and linux is letting this happen without complaint, while windows refuses.
>
> Does the same file content (ignoring expanded keywords, if any) exist at
> multiple paths? If so, such paths would naturally share the same pristine
> based on the hash of file contents.

Re: Possible apr 1.7.1 showstopper from httpd test framework

[William A Rowe Jr]

On Fri, Jan 14, 2022 at 5:44 AM Joe Orton  wrote:
>
> On Fri, Jan 14, 2022 at 11:37:35AM +0100, Ruediger Pluem wrote:
> >
> > On 1/14/22 6:47 AM, William A Rowe Jr wrote:
> > > In addition to a broken release of brotli (where enc/dec don't specify
> > > -lbrotlicommon,
> > > even on trunk, for openssl and other consumers to ferret out that 
> > > binding), and
> > > lots of fun changes to build flags in curl 7.81 minor release (who does 
> > > that?)
> > > there appears to be one test failure with date formatting in httpd 2.4.x 
> > > branch
> > > (including release 2.4.52) and apr 1.7.x branch (including release 1.7.0);
> > >
> > > t/modules/include.t . 56/98 # Failed test 64 in
> > > t/modules/include.t at line 373
> > >
> > > Have not had time to investigate whether this is a change in perl 
> > > behavior, or
> > > possibly a regression caused by apr datetime handling in 1.7.x itself., 
> > > but any
> > > release apr-side should hold off just a bit to resolve this question.
> >
> > I cannot reproduce this with APR 1.7.x on RedHat 8 and our Travis builds at 
> > least for some builds
> > on Ubuntu use APR 1.7 as well and do not fail.
> > Is this probably a Windows specific issue? Can anyone reproduce on Windows?

Fun guess. Not on Windows at the moment. This is on ubuntu 18.04
running as a vmw
workstation guest vm with the following snapshot revisions (all just a
bit beyond the
current releases, including apr 1.7;

apr_ver=1.7.x-1896808
aprutil_ver=1.7.x-1894932
brotli_rev=e83c7b8
brotli_ver=master
curl_rev=d4492b6d1
curl_ver=master
expat_rev=9c42ebdd
expat_ver=master
httpd_ver=2.4.x-1896743
httpdtest_rev=763e0201
httpdtest_ver=trunk
jansson_rev=addeeef
jansson_ver=master
libxml2_rev=dea91c97
libxml2_ver=master
lua_ver=5.4.3
nghttp2_rev=02e6cad1
nghttp2_ver=master
openssl_rev=2080da84a4
openssl_ver=master
pcre_rev=81d3729
pcre_ver=master
zlib_rev=cacf7f1
zlib_ver=master

> IIRC there is some test case which can be sensitive to filesystems, and
> e.g. sometimes fails if NFS mounted?  I may be mixing it up with another
> test. The output of "./t/TEST -v t/modules/include.t" should help
> diagnose.

I will dig deeper and check some other linux flavors.

> That phrase "including release 1.7.0" implies it's not a 1.7.x
> regression if it also failed with 1.7.0, Bill? i.e. no reason to hold up
> a release?

It's a good point, I just don't care to tag a release when we have been making
changes to apr time logic as part of the next release. Hopefully it is something
interesting in the local deployment and perhaps a bad assumption in the test?
Will report back.

Possible apr 1.7.1 showstopper from httpd test framework

[William A Rowe Jr]

In addition to a broken release of brotli (where enc/dec don't specify
-lbrotlicommon,
even on trunk, for openssl and other consumers to ferret out that binding), and
lots of fun changes to build flags in curl 7.81 minor release (who does that?)
there appears to be one test failure with date formatting in httpd 2.4.x branch
(including release 2.4.52) and apr 1.7.x branch (including release 1.7.0);

t/modules/include.t . 56/98 # Failed test 64 in
t/modules/include.t at line 373

Have not had time to investigate whether this is a change in perl behavior, or
possibly a regression caused by apr datetime handling in 1.7.x itself., but any
release apr-side should hold off just a bit to resolve this question.

And there's the issue of pcre 8.x sources no longer available for download from
ftp.pcre.org. While they still exist, there's already been one
security release that
ignored pcre 8.x considerations, so pcre 10.x obviously can't wait for httpd
release from trunk.

Re: httpd test framework svn repo borked?

[William A Rowe Jr]

Good point, thanks. Unfortunately an extra step is required if
Apache::Testcompat5005
isn't provisioned, checking out ApacheTest under this repository root
isn't automatic
with git, as with svn. Decided that Testcompat5005 is trivially
available from CPAN
and should just become another build machine prereq.

On Thu, Jan 13, 2022 at 3:28 PM Eric Covener  wrote:
>
> On Thu, Jan 13, 2022 at 4:15 PM William A Rowe Jr  wrote:
> >
> > I'm trying to work out how trunk on httpd test framework is busted on
> > Windows, irrespective
> > of using an msys2, sfl-ubuntu, or older win32 native svn build. The
> > problem always devolves
> > to something like shown below;
> >
> > svn co -q -r 1896892
> > https://svn.apache.org/repos/asf/httpd/test/framework/trunk
> > httpdtest-1896892
> > svn: E13: Can't move
> > '/c/Users/wrowe/dev/oss-httpd-build/src/httpdtest-1896892/.svn/tmp/svn-yIVLxQ'
> > to 
> > '/c/Users/wrowe/dev/oss-httpd-build/src/httpdtest-1896892/.svn/pristine/b4/b4648076d6b2a3dfab889875d892252d5ed2594c.svn-base':
> > Permission denied
> > make: *** [../mak/Makefile.download:36: httpdtest-1896892] Error 1
> >
> > The file it is attempting to move to already exists (why?) Any
> > guidance is appreciated, since
> > it is painful to grab this on a native ubuntu vm and slough it back to
> > windows to be able
> > to run the framework on windows.
>
> No clue on the error but the r/o git mirror is at least something else
> to try: g...@github.com:apache/httpd-tests.git
> When we had intermittent SVN errors in the travis builds, we pulled
> from this instead.

Re: httpd test framework svn repo borked?

[William A Rowe Jr]

Thanks Stefan, it's attempting [locally] to replace a file, which was
just created during the
checkout (which might even be open). So it looks like some hash
collision or other
duplication issue where there are two attempts to emplace the same
hash svn-base image,
and linux is letting this happen without complaint, while windows refuses.

(At first I suspected a strange file perms issue or a conflicting file
name case issue, but
this is not the situation.)


On Thu, Jan 13, 2022 at 3:34 PM Stefan Sperling  wrote:
>
> On Thu, Jan 13, 2022 at 03:14:55PM -0600, William A Rowe Jr wrote:
> > I'm trying to work out how trunk on httpd test framework is busted on
> > Windows, irrespective
> > of using an msys2, sfl-ubuntu, or older win32 native svn build. The
> > problem always devolves
> > to something like shown below;
> >
> > svn co -q -r 1896892
> > https://svn.apache.org/repos/asf/httpd/test/framework/trunk
> > httpdtest-1896892
> > svn: E13: Can't move
> > '/c/Users/wrowe/dev/oss-httpd-build/src/httpdtest-1896892/.svn/tmp/svn-yIVLxQ'
> > to 
> > '/c/Users/wrowe/dev/oss-httpd-build/src/httpdtest-1896892/.svn/pristine/b4/b4648076d6b2a3dfab889875d892252d5ed2594c.svn-base':
> > Permission denied
>
> This has nothing to do with the server, it is some problem with the
> working copy which is being checked out.
>
> It looks as if MoveFileExW is failing with EACCESS, see here:
> https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/io.c?view=annotate#l4529
> Though depending on which version of svn you have installed, svn might
> be calling directly into APR instead and fail there.
>
> > make: *** [../mak/Makefile.download:36: httpdtest-1896892] Error 1
> >
> > The file it is attempting to move to already exists (why?) Any
> > guidance is appreciated, since
> > it is painful to grab this on a native ubuntu vm and slough it back to
> > windows to be able
> > to run the framework on windows.
> >

httpd test framework svn repo borked?

[William A Rowe Jr]

I'm trying to work out how trunk on httpd test framework is busted on
Windows, irrespective
of using an msys2, sfl-ubuntu, or older win32 native svn build. The
problem always devolves
to something like shown below;

svn co -q -r 1896892
https://svn.apache.org/repos/asf/httpd/test/framework/trunk
httpdtest-1896892
svn: E13: Can't move
'/c/Users/wrowe/dev/oss-httpd-build/src/httpdtest-1896892/.svn/tmp/svn-yIVLxQ'
to 
'/c/Users/wrowe/dev/oss-httpd-build/src/httpdtest-1896892/.svn/pristine/b4/b4648076d6b2a3dfab889875d892252d5ed2594c.svn-base':
Permission denied
make: *** [../mak/Makefile.download:36: httpdtest-1896892] Error 1

The file it is attempting to move to already exists (why?) Any
guidance is appreciated, since
it is painful to grab this on a native ubuntu vm and slough it back to
windows to be able
to run the framework on windows.

Re: annou...@httpd.apache.org [moderator] missing

[William A Rowe Jr]

Stefan,

thanks for RM'ing!

On Fri, Oct 8, 2021 at 3:10 AM ste...@eissing.org  wrote:
>
> The 2.4.51 announcement on annou...@httpd.apache.org did not make it, as seen 
> in the mailing list archives.
>
> I have no idea why not. Any moderator of that list here?

Still no sign of it in httpd-announce, the www-announce did make it.
Any chance you had used a different email sender to httpd? You could
try a ping to announce-owner@. Sebb would you happen to have a list of
the current httpd-announce moderators? Are any active PMC members
interested in helping? (Due to the from-@apache restriction, it's
comparatively spam-free.)

Also a post-release cleanup step to add,
https://downloads.apache.org/httpd/ is growing further out of date.
This should contain only the current release except during the release
transition. In the day it takes to copy to the mirrors, the new
release will also be picked up permanently by archive.apache.org. So
once the website links are all updated, the previous release should be
removed to invalidate stale links.

Re: pollset WAKEABLE

[William A Rowe Jr]

On Tue, Sep 28, 2021, 07:22 ste...@eissing.org  wrote:

>
> > Am 28.09.2021 um 14:10 schrieb ste...@eissing.org:
> >
> >> Am 28.09.2021 um 14:04 schrieb Yann Ylavic :
> >>
> >> On Tue, Sep 28, 2021 at 1:08 PM ste...@eissing.org 
> wrote:
> >>>
> >>> Does anyone know which platforms do *not* support WAKEABLE apr
> pollsets?
> >>
> >> Last time I checked (IIRC) all platforms support it on the APR side,
> >> every platform handles pipes at least it seems.
> >> Possibly it wasn't the case some (long) time ago, we are probably
> >> overly cautious with APR_POLLSET_WAKEABLE availability check in
> >> mpm_event..
> >>
> >>>
> >>> And if http2 should support this, would be adding an own wakeup pipe
> be the way to go?
> >>
> >> Looks overly cautious to me :)
> >
> > Uhm, due to an error report from Windows, I am reading the APR pollset
> > implementation again. And Windows does not support polling on pipes?
> >
> > There is a special hack inside apr to realize a wakeup pipe,
> > but otherwise it returns APR_EBADF. If I read it correctly...
> >
> > That would pose some major difficulties.
>
> Hmm, apr_file_pipe_create() under Windows makes me cry...
>

Indeed, what you think of as pipes are not what windows implemented, and
while they have been stdio for years, the left a lot to be desired.

This means I need another strategy under Windows. *sadge*
>

Such as true AF_UNIX pipes, introduced after the initial launch of Window
10/Server 2019. And can do one better in Server 2022/Windows 11 with actual
edge triggered eventing.

To bake this into apr, it needs to be run-time detected, at least if there
continues to be a single binary for apr-1.dll, but our feature macros are
all compile time.

Compound this with the fact that MS supports named pipes, but isn't
supporting socketpair to create a usefully unnamed pipe.

None of this will work in the initial Windows 10/Server 2019 releases.

At least this opens up a number of options that had been missing for 25
years.

Re: APR 1.7.1 release?

[William A Rowe Jr]

I'm willing to RM APR and APR-util 1.7 releases.

Would propose we set a date out 2 weeks, anything lingering needs
to be finalized with the usual oversight no later than the 8th, and
we tag on the 14th, announce on the 15th when the mirrors have
caught up. That gives enough days for committers to review the
last changes to these release branches.

But I'd be happier co-RM'ing this with a newer committer/PMC
participant who wants to learn the ropes. Any volunteers?
Other thoughts or observations?

On Tue, Aug 31, 2021 at 3:09 AM Rainer Jung  wrote:
>
> Hi there,
>
> any chance we find an RM for a APR 1.7.1 release? At least there was the
> fix for CVE-2021-35940 and CHANGES contains 15 more items (many of them
> platform specific or build improvements). Last release 1.7.0 was in
> April 2019.
>
> For APR-util I don't know the current state and release needs for the
> 1.6.x and 1.7.x branches. Last 1.6.x release was in October 2017, 1.7.x
> has never been released. CHANGES for 1.6.x only contains one
> apr_dbm_gdbm fix plus a minor libtool use improvement.
>
> Apache httpd is planing to start a release cycle soon and it would be
> nice to have a clean APR 1.7.1 and maybe APR-util also.
>
> Thanks and regards,
>
> Rainer

Re: [RESULT - PASS] Release httpd-2.4.48

[William A Rowe Jr]

This always happens, remember you must send announcement.*@a.o mail
from an @a.o address. Which is extra confusing if you haven't set up
the SMTP validation yet.

On Tue, Jun 1, 2021 at 4:07 PM Christophe JAILLET
 wrote:
>
> Le 01/06/2021 à 03:07, William A Rowe Jr a écrit :
> > Christophe, thanks for your energetic efforts to kick off the next release!
> >
> > I looked for the post but couldn't find it, the community is confused.
> > Is this release pulled for regressions? It hasn't been communicated
> > well, but the release is sitting on every mirror, since 6 to 24 hours
> > after you placed it on dist.
> >
> > Inquiring minds would like to know, you seem to confirm this release in
> > this specific post, so it appears that it has happened, even if adopting
> > it is unwise.
> >
>
> Hi,
>
> 2.4.48 is live now.
>
> However, the mails sent on annouce@a.o and annouce@httpd.a.o seem to not
> have reached their destination yet.
> Maybe a moderation issue on the lists.
>
> As you can see, there is also some security related fixes. There are
> listed at [1].
>
> I still need to figure out a few things with our new CVE management
> mechanism. So our vulnerability listing ([2]) with some more details is
> not updated yet. I hope to be able to update it in the coming days.
>
> Most CVE fixed in this release are rated from moderate to low impact.
> Only one, CVE-2021-31618 is rated as important and could be exploited
> for some DoS.
>
> Christophe JAILLET
>
>
> [1]: https://downloads.apache.org/httpd/CHANGES_2.4.48
> [2]: https://httpd.apache.org/security/vulnerabilities_24.html

Re: [RESULT - PASS] Release httpd-2.4.48

[William A Rowe Jr]

Christophe, thanks for your energetic efforts to kick off the next release!

I looked for the post but couldn't find it, the community is confused. Is
this release pulled for regressions? It hasn't been communicated well, but
the release is sitting on every mirror, since 6 to 24 hours after you
placed it on dist.

Inquiring minds would like to know, you seem to confirm this release in
this specific post, so it appears that it has happened, even if adopting it
is unwise.

On Tue, May 25, 2021 at 12:59 PM Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

> Hi all,
>
> With 8 binding PMC +1 votes, 5 additional +1 votes from the community,
> and no -1 votes, I'm pleased to report that the vote has PASSED to
> release 2.4.48.
>
> The process of pushing to the distribution mirrors is one the way. I
> should make the announcement in the coming days.
>
>
>
> Here are the votes I have recorded during the thread:
> (apologies if I missed someone)
> PMC:
>  dferradal, jfclere, gbechis, jailletc36, jorton, rjung, steffenal,
>  ylavic
>
> Community and committers:
>  Noel Butler, Jan Ehrhardt, Cory McIntire, William A Rowe Jr (wrowe),
>  Ivan Zhakov (ivan)
>
>
> The systems that have been tested on include:
>  CentOS 6, 7, 8
>  Debian
>  Fedora 34
>  RHEL 6, 7, 8
>  Slackware 14.0, 14.2 and 15 beta
>  SLES 11, 12, 15
>  Solaris 10   (Sparc)
>  Ubuntu 21.04
>  Windows   (x86 and x64)
>
>
> Thanks to all of you for your time and cycles for testing on all these
> different platforms and configurations.
>
> Christophe JAILLET
>

Re: Question about APR trunk and httpd ldap modules

[William A Rowe Jr]

On Sat, May 29, 2021 at 11:55 AM Roy T. Fielding  wrote:

> On May 28, 2021, at 9:59 AM, William A Rowe Jr 
> wrote:
>
> AIUI, as he remains a PMC member, the veto remains binding per Roy's
> conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so
> just sharing historical pointers for those raising questions, no opinion
> remaining of HTTP Server PMC choices at all. But I did want to point out
> that the project did choose to ignore the vastly more secure PCRE 10
> rewrite and is still stuck at PCRE 8 (although I run bleed builds all the
> time of httpd trunk X apr 2 trunk X pcre 10 with no issues at all.) In
> theory, if the APR project has enough maintainers (minimum 3, more + than -
> votes), then apr[+util] 1.x might persist for years after a 2.0 release, if
> such a release occurs.
>
>
> The veto, like any veto, was specific to both the context at the time
> (2.4.0)
> and the change being made. The way to resolve it is to work together
> towards either a common solution (in APR) or a narrow change (in httpd).
>

I think everyone shares this sentiment, although your timeline is just a
bit off,
this was at 2.3 alpha as we were approaching beta, as the same time as the
APR project was looking forward at a version major release that hasn't
occurred since then.

The way to not get anything done in ten years is to claim that someone
> doesn't have the right to veto a change, and then insist on having the
> high ground instead of working toward anything.
>

You might be confused, I acknowledged the veto 10 years ago, the only
thing that hasn't happened in 10 years is that the API within the APR
project
didn't lose its dependency on another project's header files, and the veto
lives on at httpd to adopt the code the APR crew collectively and nearly
unanimously threw off the boat as incomplete for a 2.0 release. I never
rejected anyone's efforts to advance the exact API at httpd, and never
rejected any effort anyone would bring to APR to isolate the dependency
chain to APR's headers alone. But you know more than anyone that what
is decided for APR is decided by APR, and this is the wrong list to discuss
that side of the equation. The many of us looked to your guidance through
this discussion Roy, and I accepted whatever you concluded, at both of the
projects, as I think most other participants did.


> Projects don't *do* things; people do, preferably while working together
> within the same project. It is much harder for people to do things together
> when individuals are being painted into a corner, having their concerns
> disregarded, or repeatedly being attacked just because you don't agree
> with one decision they made.
>

You. I'm taking that personally, but it's irrelevant, I'm not a PMC member
here at httpd, and I haven't been in the way of any committee business
for nearly 2 years. I jumped off the administration of this teetering barge
a while ago to let other headstrong people pilot it and give my head and
heart a break from the inanity.


> I suggest that the way to fix this tiny little problem is to create a new
> LDAP secure client library in httpd that has the very specific purpose
> we need (call it ap_ldapsc_*) and then change httpd's current usage to
> make use of that library instead. If that leads to enough energy to
> eventually become a common utility on its own, then it can migrate
> to a common LDAP library (not necessarily APR) at that later time.
>

That sounds great, I'm sure the httpd community can get behind any
workable solution (and perhaps, it doesn't have to be that complex,
sounds like a workable APR solution even.) In any case, a veto by the
author themself of their own code is a most strange thing that's ever
happened at the ASF.

Likewise, the way to update to PCRE 10 is to do the work necessary for
> the update, including backwards compatible shims. It would make for
> a good entry/student project.
>

Indeed, since I also did that work almost a decade ago, it's waiting for
a trivial change to configure.in - and a possible optimization since stack
is off the table due to the recursive complexity of regex expansion, and
we never quite settled on our thread local storage best practice.

Also, to Stefan, yes I recognized your coding pattern as making it very
simple to drop in a less complex client implementation than libcurl. It's
just so odd that we have a client all baked out in httpd, it's called
mod_proxy_http, but basically it can't be repurposed. Pretty strange,
I'm glad a few committers tried to tackle serf in the first place based
on that gap and subversion's needs.

I look forward to seeing what/how the httpd community collectively
decides to move forward, I'm liking the dialog on how to catalog the
changes history.

Re: Question about APR trunk and httpd ldap modules

[William A Rowe Jr]

On Thu, May 27, 2021 at 8:42 PM William A Rowe Jr 
wrote:

> On Thu, May 27, 2021, 07:52 Eric Covener  wrote:
>
>> On Thu, May 27, 2021 at 8:45 AM Rainer Jung 
>> wrote:
>>
>> > is my understanding correct, that even httpd trunk (and then also 2.4.x)
>> > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap?
>> >
>> > So since we removed LDAP support from APR trunk, that means those
>> > modules currently can not be build using APR trunk, neither in httpd
>> > trunk nor in httpd 2.4.x. Correct?
>>
>> I think this is correct.  This was a pretty heated/sore issue to my
>> recollection. Only the removal got done.
>>
>
> That's nearly correct.
>
> The port to ap_ namespace was composed and committed to httpd trunk, by
> myself. And in the heat of the argument, vetoed by the obvious party, so I
> reasonably promptly reverted that, without a few minor tweaks that were
> still necessary across various platforms or httpd build scenarios.
>

Actually, sf was kind enough to perform the revert, which included the
initial work and several other committer's fixes;
https://svn.apache.org/viewvc?view=revision=1150179

Initial vote discussion (similar to what we are having) occurred here;
http://mail-archives.apache.org/mod_mbox/httpd-dev/201107.mbox/%3c4e15e51e.4090...@rowe-clan.net%3e

The veto of httpd accepting the ap_ldap code from APR happened here;
http://mail-archives.apache.org/mod_mbox/httpd-dev/201106.mbox/%3c4192dc1d-c0b9-42bb-b614-c3a41290f...@sharp.fm%3E

AIUI, as he remains a PMC member, the veto remains binding per Roy's
conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so
just sharing historical pointers for those raising questions, no opinion
remaining of HTTP Server PMC choices at all. But I did want to point out
that the project did choose to ignore the vastly more secure PCRE 10
rewrite and is still stuck at PCRE 8 (although I run bleed builds all the
time of httpd trunk X apr 2 trunk X pcre 10 with no issues at all.) In
theory, if the APR project has enough maintainers (minimum 3, more + than -
votes), then apr[+util] 1.x might persist for years after a 2.0 release, if
such a release occurs.

Re: Question about APR trunk and httpd ldap modules

[William A Rowe Jr]

On Thu, May 27, 2021, 07:52 Eric Covener  wrote:

> On Thu, May 27, 2021 at 8:45 AM Rainer Jung 
> wrote:
>
> > is my understanding correct, that even httpd trunk (and then also 2.4.x)
> > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap?
> >
> > So since we removed LDAP support from APR trunk, that means those
> > modules currently can not be build using APR trunk, neither in httpd
> > trunk nor in httpd 2.4.x. Correct?
>
> I think this is correct.  This was a pretty heated/sore issue to my
> recollection. Only the removal got done.
>

That's nearly correct.

The port to ap_ namespace was composed and committed to httpd trunk, by
myself. And in the heat of the argument, vetoed by the obvious party, so I
reasonably promptly reverted that, without a few minor tweaks that were
still necessary across various platforms or httpd build scenarios.

But you can find nearly all the necessary work on httpd trunk history, if
there's a desire to ressurect the ability for httpd to survive an apr 2
release. It didn't matter for PCRE, so I don't know that it is a priority.

Any discussion w.r.t. apr project belongs at that project, if there's a
desire to cause some action there. Based on observations of the huge scale
of Curl vulnerabilities (which hit us for mod_md, because that is libcurl,
as opposed to serf or something straightforward as the letsenrypt client),
and on some additional thoughts shared on apr about further modularizing
and disconnecting the each-and-every-facility from core apr+util, that
would be an interesting discussion to have. But it might have even more
additional resistance based on today's security postures, based on
dependencies of dependencies security history.

Re: [VOTE] Release httpd-2.4.48

[William A Rowe Jr]

The bandages back-ported from trunk resolved all the lua 5.4 issues... +1
from the peanut gallery for this candidate.

On Mon, May 17, 2021, 16:37 Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.48:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
> sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e
> *httpd-2.4.48.tar.gz
> sha512:
> 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb
>
> *httpd-2.4.48.tar.gz
>
> The SVN tag is '2.4.48' at r1889975.
>
> --
> Christophe JAILLET
>

Re: [VOTE] Release httpd-2.4.46

[William A Rowe Jr]

Following the announcement link, it isn't clear that

https://httpd.apache.org/security/vulnerabilities_24.html

fixes issues in 2.4.46.

Should the fixed-in be promoted to the revision of Apache HTTP Server
actually published (released) by the project? It almost reads like "fixed in
2.4.46-dev" (which 0-day disclosures are described as, until a release
is actually published.)

On Wed, Aug 5, 2020 at 6:32 AM Daniel Ruggeri  wrote:

> Hi, all;
>
>With 12 binding PMC +1 votes, two additional +1 votes from the
> community, and no -1 votes, I'm pleased to report that the vote has
> PASSED to release 2.4.46. I will begin the process of pushing to the
> distribution mirrors which should enable us for a Friday announcement -
> a great way to wrap up the week!
>
> Here are the votes I recorded during the thread:
> PMC
> jailletc36, steffenal, elukey, jorton, jfclere, ylavic, covener,
> gbechis, gsmith, druggeri, jblond, rjung
>
> Community
> Noel Butler, wrowe
>
> --
> Daniel Ruggeri
>
> On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
> > Hi, all;
> >Third time is a charm! Please find below the proposed release tarball
> > and signatures:
> > https://dist.apache.org/repos/dist/dev/httpd/
> >
> > I would like to call a VOTE over the next few days to release this
> > candidate tarball as 2.4.46:
> > [ ] +1: It's not just good, it's good enough!
> > [ ] +0: Let's have a talk.
> > [ ] -1: There's trouble in paradise. Here's what's wrong.
> >
> > The computed digests of the tarball up for vote are:
> > sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
> > sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
> > *httpd-2.4.46.tar.gz
> > sha512:
> >
> 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
> > *httpd-2.4.46.tar.gz
> >
> > The SVN tag is '2.4.46' at r1880505.
> >
>
>

Re: Inexplicable sporadic 404 & 301 responses

[William A Rowe Jr]

Folks, the hostility in this exchange isn't appropriate, especially the
later messages.

On Mon, Aug 3, 2020 at 2:35 AM JunkYardMail1 
wrote:

> Getting sporadic not found (404) and redirects (301).  These occur maybe
> about 1 per 1000+ or so.
>
> The 404 responses are for existing content, and the 301 response make no
> sense.  Sometimes the redirect is to the same URL that was requested or to
> something completely unrelated.
>
> I can go to these URL's just fine without getting not found or redirect.
>
> Apache/2.4.6 (CentOS)
> Apr  2 2020 13:13:23
>

This is, as pointed out, a users@ question. Please do be considerate of the
fact
that the developers spend their limited cycles to address problems in the
current
source code, and the request doesn't identify a source code defect.


> perhaps try something a little more modern, 2.4.6 is _40_ releases old,


That's not true, because (as you can see today)...


> ASF is about to release 2.4.46
>

and the 2.4.45 and 2.4.44 versions were not released. There are 16 skipped
releases,
and only 24 released versions of httpd 2.4 since 2.4.6 in July of 2013, 7
years ago.
Either way, this is too old for the developers to spend attention on, as it
has little
relevance to the current project source code under development.

This is a factual statement, if a bit blunt:

and this question is better suited to users@  not dev@
> --
> Regards,
> Noel Butler
>


> It is the package that is provided to CentOS 7.  I'm not interested in
> spending my life compiling packages.
>

And CentOS 8 is celebrating its first birthday in 7 weeks.  Developers and
fellow
users are more inclined to answer questions directed at current operating
systems.
CentOS 7 maintainers will only be providing full updates into Q4 of this
year, with limited
maintenance patches into 2024. For support from the CentOS community, it's
a good time
to be migrating. As far as compiling packages, there are other rpm
distribution channels
to keep up with a more up-to-date flavor httpd without compiling packages.

Let's try to keep thread redirections reasonably polite and presume best
intentions?

Re: [VOTE] Release httpd-2.4.46

[William A Rowe Jr]

On Sat, Aug 1, 2020 at 9:13 AM Daniel Ruggeri  wrote:

> Hi, all;
>Third time is a charm! Please find below the proposed release tarball
> and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/


Just as a footnote to 2.4.46, as mentioned before mod_lua won't compile
against the
current lua release 5.4.0. Can this be mentioned in the release
announcement that
the lua 5.3.5 release or earlier is still required? (It's my guess that
after breaking the
API with the release of 5.4.0, they aren't about to revert that change in a
later flavor.)

Re: [VOTE] Release httpd-2.4.46

[William A Rowe Jr]

On Sat, Aug 1, 2020 at 9:13 AM Daniel Ruggeri  wrote:

> Hi, all;
>Third time is a charm! Please find below the proposed release tarball
> and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.46:
>

>From the peanut gallery;

[✔] +1: It's not just good, it's as good as can be expected!

Windows via cmake, ubuntu 16, 18, 20 LTS's and centos 7, 8.

Re: First impressions from OpenSSL 3.0.0 and httpd 2.4.45

[William A Rowe Jr]

On Sat, Aug 1, 2020 at 10:44 AM Rainer Jung  wrote:

> Hi there,
>
> during release testing for 2.4.45 I also built and tested using OpenSSL
> 3.0.0alpha5 on the server. Overall first results are pretty good:
>

This is pretty awesome, thanks! Beyond the usual current packages, I'm also
doing a snapshots against released maintenance branch snapshots all our
dependencies when available (e.g. the working branch for lua is not
apparent),
so 2.4.46 is validated against;

apr_rev=1878356
apr_srcpath=https://svn.apache.org/repos/asf/apr/apr/branches/1.7.x
apr_ver=1.7.x-1878356
apriconv_rev=1872196
apriconv_srcpath=https://svn.apache.org/repos/asf/apr/apr-iconv/trunk
apriconv_ver=1.3.x-1872196
aprutil_rev=1880287
aprutil_srcpath=https://svn.apache.org/repos/asf/apr/apr-util/branches/1.7.x
aprutil_ver=1.7.x-1880287
brotli_rev=0c5603e
brotli_srcpath=https://github.com/google/brotli
brotli_ver=master
curl_rev=2b6b843bb
curl_srcpath=https://github.com/curl/curl
curl_ver=master
expat_rev=990e3d0
expat_srcpath=https://github.com/libexpat/libexpat
expat_ver=master
httpd_pkg=httpd-2.4.46.tar.bz2
httpd_srcpath=https://httpd.apache.org/dev/dist
httpd_ver=2.4.46
httpdtest_rev=1880510
httpdtest_srcpath=
https://svn.apache.org/repos/asf/httpd/test/framework/trunk
httpdtest_ver=1880510
jansson_rev=73ccec0
jansson_srcpath=https://github.com/akheron/jansson
jansson_ver=master
libxml2_rev=21ca8829
libxml2_srcpath=https://github.com/gnome/libxml2
libxml2_ver=master
lua_pkg=lua-5.4.0.tar.gz
lua_srcpath=https://www.lua.org/ftp
lua_ver=5.4.0
nghttp2_rev=4ecdc290
nghttp2_srcpath=https://github.com/nghttp2/nghttp2
nghttp2_ver=master
openldap_rev=63d6f680b
openldap_srcdir=openldap-2.x-63d6f680b
openldap_srcpath=https://git.openldap.org/openldap/openldap.git
openldap_ver=master
openssl_rev=6328d3673f
openssl_srcpath=https://github.com/openssl/openssl
openssl_ver=OpenSSL_1_1_1-stable
pcre_rev=1763
pcre_srcpath=svn://vcs.exim.org/pcre/code/trunk
pcre_ver=8.x-1763
zlib_rev=cacf7f1
zlib_srcpath=https://github.com/madler/zlib
zlib_ver=master

Based on your progress, I'm promoting openssl 3.0.0 branch from bleed to
snapshot status today as the maintenance branch of that dependency, thanks
to your validations!

Appreciated, and cheers,

Bill

(See https://github.com/appsuite/oss-httpd-build/ for reproducing such
speculative snapshot or bleed builds.)

Re: [VOTE] Release httpd-2.4.45

[William A Rowe Jr]

On Thu, Jul 30, 2020 at 3:19 PM Daniel Ruggeri  wrote:

>
> On 7/30/2020 2:41 PM, William A Rowe Jr wrote:
>
> On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  wrote:
>
>>
>> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET <
>> christophe.jail...@wanadoo.fr> wrote:
>> >
>> > I wouldn't say it is a show stopper, but I thought that we had a travis
>> job for that.
>> > Apparently, it is on trunk only (see r1879370 which is not backported,
>> maybe on purpose)
>>
>> I agree that it's not a show-stopper but it is something that seems easy
>> to fix and, considering that (1) we want to release the best possible
>> version as we can and (2) there is quite a bit of time between releases, I
>> wouldn't be opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.
>>
>
> Agreed. And Steffen points out there is precedence.
>
> Aye - and I'd hate to appear inconsistent :-)
>
> Version numbers are cheap - I'll re-roll when we have confirmation all is
> good in the 2.4 branch.
>

Released on Jun 29th, we do not compile against lua 5.4.0. A possible fix
is described here;

https://github.com/apache/httpd/pull/133

If there is anyone very savvy with lua coding, it would be good to identify
the best approach for compatibility. (It may not be realistic to solve this
in 2.4.46.)

Re: [VOTE] Release httpd-2.4.45

[William A Rowe Jr]

On Thu, Jul 30, 2020 at 10:10 AM Jim Jagielski  wrote:

>
> > On Jul 30, 2020, at 5:55 AM, Christophe JAILLET <
> christophe.jail...@wanadoo.fr> wrote:
> >
> > I wouldn't say it is a show stopper, but I thought that we had a travis
> job for that.
> > Apparently, it is on trunk only (see r1879370 which is not backported,
> maybe on purpose)
>
> I agree that it's not a show-stopper but it is something that seems easy
> to fix and, considering that (1) we want to release the best possible
> version as we can and (2) there is quite a bit of time between releases, I
> wouldn't be opposed if the RM decided to skip 2.4.45 and go w/ 2.4.46.
>

Agreed. And Steffen points out there is precedence.

Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize

[William A Rowe Jr]

On Mon, Jul 20, 2020, 10:24 Ruediger Pluem  wrote:

>
>
> On 7/20/20 4:45 PM, Yann Ylavic wrote:
> > On Thu, Jul 16, 2020 at 10:31 PM Eric Covener  wrote:
> >>
> >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem 
> wrote:
> >>>
> >>>
> >>>
> >>> On 6/24/20 1:27 PM, Eric Covener wrote:
> >
> > ProxyMappingDecoded is not needed anymore (and was removed).
> > The mapping= tells mod_proxy at which stage ([pre_]translate) it
> > should map the request path.
>  +1
> 
> >>>
> >>> Getting back to an old topic. Shouldn't we have a directive similar to
> >>> AllowEncodedSlashes that allows us to block URI's that contain
> >>> URL fragments like /.; and /..; in order to avoid that someone plays
> >>> silly games that bypass Location settings and RewriteRules
> >>> that might be used with a servlet engine in the backend? Happy
> >>> to have that set to a default that allows /.; and /..;.
> >>
> >> +, but I'd want the safer default.
> >
> > Is this something we should care about outside the proxy mapping=servlet
> case?
> > In the other cases, "/.;" and "/..;" are nothing but plain text (they
> > won't be treated as "/." and "/.." on the filesystem AFAICT), so we
> > could let them 404 normally.
>
> I think for the default handler this is no problem. As you state such
> URL's likely produce just a 404 and we are done.
>
> > In the mapping=servlet case, servlet normalization is applied to
> > r->[parsed_]uri (no "/.;" or "/..;" anymore), so Location/.. matchings
> > use the same uri-path than the backend.
>
> But only if you have an appropriate ProxyPass in place. With RewriteRules
> this does not work.
> Hence I think we need an additional mechanism to handle this in case of no
> ProxyPass directives.
> I still fail to see a real use case for /..; and /.; segments. Hence I
> think denying them should
> be possible with a simple option without the need for a ProxyPass
> directive or an additional
> RewriteRule. This would also keep path parameters in other segments as
> they are.
> As said I am even happy if the default of this directive would keep the
> current behavior.
>
> > This sounds a bit like we want to reject "/.;" or "/..;" for the
> > servlet case but still accept "/." and "/.." unconditionally for the
> > non-servlet case. So possibly we want a general "AllowPathTraversal"
> > directive (off by default) for the core to allow/reject "." and ".."
> > AND proxy mapping=servlet to extend it to "/.;" or "/.;" (and probably
> > "/;" too since it's the same as "/.;" when MergeSlashes applies)?
>
> I don't want to allow/deny '.' and '..'. Without path parameters I just
> want to remove ('.') / shrink them ('..') without going
> past root like we do today.
>

>From the beginning of this dialog, that isn't the function of an HTTP/1
proxy. We have no business in that PER THE SPECS.

I don't understand why the Tomcat project and other servlet providers,
after given evidence they broke the spec, and downgrade of their
reservations of the ;params logic out of the URI spec, keep insisting the
behavior is necessary for the HTTP transport providers to consider.

I don't understand why, Ruediger, some keep defending the .; or ..; as a
normative acceptable path element, and refuse to consider the idea that
every such occurance is malicious, without evidence of a single legit
application of that formation.

If you don't want to let them slide, we *could* deny \.;.* and \.\.;.* by
default. Or we already *can* when ajp users would like to add rewrite rules.

Re: iOS 14 / macOS 11 and HTTP/3 support

[William A Rowe Jr]

On Sun, Jun 28, 2020 at 5:53 AM Graham Leggett  wrote:

> On 27 Jun 2020, at 14:48, Luca Toscano  wrote:
>
> > the challenges are the same one discussed in your previous email
> > thread (
> https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E
> ).
> > I think that everybody would love to start working/helping on adding
> > HTTP/3 support but the work to be done is huge, involves invasive
> > changes to the httpd's source code and the current dev resources don't
> > have (rightfully) bandwidth to support the current codebase and plan a
> > major refactoring.
>
> I would be careful with wide reaching statements like this.
>
> I’ve been working on identifying and removing blockers in various parts of
> the httpd subsystems that prevent httpd to be cleanly event driven, and
> most of those blockers have been removed.
>
> The underlying architecture of httpd is very strong, and would support new
> protocols without too much trouble.
>
> The main point is that it must be done carefully and properly, but this is
> not a reason to not do it at all.
>

I didn't read anyone saying "don't do it", in fact all the communication
has said exactly the opposite.

Irrespective of getting the code into a state where true async behavior
"just works", and request handlers will have no problem with free threading
(this is not true of PHP and other third party modules), that still leaves
a huge hole.

Right now, we couple httpd <-> mod_ssl <-> mod_http2 <-> nghttp2 <-> httpd
filters and handler. This works, since the protocol layer exists apart from
the SSL stack.

What we are running up against at another project is the tight interconnect
between the ssl protocol implementation and the quic implementation. They
are almost insperable. You can't do this with mod_ssl out-of-the-box. There
are hacks of mod_ssl to enable the callbacks and sideways ingress points
which the quic transport protocol requires, but effectively it's a marriage
between Google's quiche and boringssl, or another quic implementation and
their elected ssl transport.

So it might be that mod_ssl almost entirely disappears in this scenario,
replaced by a triplet of httpd skin around one specific quic tightly
coupled to one specific tls provider.

The openssl project has published that following 3.0.0 GA, they are
devoting energies into implementing all of the hooks into openssl required
of a quic implementation (alongside building a FIPS crypto provider coupled
to 3.0.0.) These were simply things that current 3.0.0 release plan
couldn't accommodate, and they were further worried that the specifics of
the spec weren't sufficiently ironed out during their pre-alpha development
stage to commit to 10+ years of support for mangled API's.

Tatsuhiro himself has been contributing commits to
https://github.com/ngtcp2/nghttp3 although I have yet to read any specific
roadmap or plan on what direction he is taking his efforts. At $dayjob OSS
projects, it's largely been a matter of consuming his implementation of
nghttp2, while consuming boringssl+quic to get to http3 for the time being.

I don't think Luca's general guidance is off-base, nor that his cautions
are at all misplaced, and he has perhaps taken a fair assessment of the
complexity of this challenge.

Re: Reject HTTP protocols >= 2.0 in ap_parse_request_line?

[William A Rowe Jr]

>  On 6/18/20 12:09 AM, Roy T. Fielding wrote:
> >> On Jun 8, 2020, at 12:56 AM, Ruediger Pluem 
> wrote:
> >>
> >> I came across the question if we should not reject HTTP protocols
> >= 2.0 in the request line when we parse it
> >> in ap_parse_request_line.
> >> This does not affect mod_http2 if loaded as HTTP/2.0 connections
> itself are not parsed via ap_parse_request_line
> >> and sending a
> >>
> >> GET /something HTTP/2.0
> >>
> >> as request line is not a valid way to start a HTTP 2.0 connection
> and I doubt that it will be for future major versions.
>

Correct, it starts an HTTP/1.1 connection, and the response should reflect
HTTP/1.1.

> That isn't how these things typically work. New protocols are
> > advanced with either deliberate backwards-compat or deliberate
> > backwards-break, with an expectation that it will either do
> > something useful on an older-protocol server or cause a safe
> > error in an expected way.
> >
> > Hence, we might still see an HTTP/4.0 that is designed to be
> > parsed like HTTP/1.1 (by an old server) while at the same time
> > work perfectly for a new server. That would be some hefty magic,
> > but it remains possible. Likewise, we might want to deploy a
> > version of h2 or HTTP/3 that works on unix domain sockets or
> > localhost over non-Internet TCP.
> >
> > This is why the existing code did not error on protocols >= 2.0.
> > Doing so is both unnecessary and counterproductive. If parsing
> > fails for some other reason, we want that other reason to be
> > in the response (because that's what the new protocol will be
> > expecting from an old protocol server). If it doesn't fail, we
> > want to provide the successful response because the request
> > was deliberately crafted that way to save a round trip.
> >
> > Note that the incoming request protocol version should always
> > be distinct from any forwarded request protocol or response
> > protocol versions.
>

Precisely. If mod_http2 or quic/mod_http3 can do something with the
connection
based on the request line, it's up to them through the hook facility to
take ownership
of the connection.

If they cannot/do not, then the core http1 connection/request processors
remain
in place and in response to "please speak in HTTP/4.0" this server will
respond,
"sure, here is your HTTP/1.1 response" as expected and defined by the RFC.

Re: Building from svn on MacOS

[William A Rowe Jr]

On Mon, Apr 13, 2020 at 4:21 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> William,
>
> >> I'm having some trouble building 2.4.x directly from svn.
> >>
> >> MacOS 10.14.6 (Mojave)
> >
> > I note you mentioned apr 1.7.0. If you grab and pre build apr, and
> > then apr-util (and openssl and anything else you want to refresh)
> > or install the compiled system package, it should work. Point at
> > them --with-apr plus --with-aprutil.
>
> I'm using brew which is like the missing package manager for macos.
> I've installed apr and apr-util which I thikn are both binary
> packages. I reconfigured with:
>
> $ ./buildconf --with-apr=/usr/local/Cellar/apr/1.7.0/bin/apr-1-config
> - --with-apr-util=/usr/local/Cellar/apr-util/1.6.1_3/bin/apu-1-config
>
> I get this output:
>
> using apr-config version 1.7.0
> ./buildconf: line 249: cd:
> /usr/local/Cellar/apr-util/1.6.1_3/bin/apu-1-config: Not a directory
> copying build files
>

That's your answer. It wants the parent path of the apr/apr-util
installations,
not the name of the apr-1-config file. It will work out bin/apr-1-config...
etc.

Re: Building from svn on MacOS

[William A Rowe Jr]

On Mon, Apr 13, 2020, 11:41 Eric Covener  wrote:

> On Mon, Apr 13, 2020 at 12:19 PM Christopher Schultz
>  wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > All,
> >
> > I'm having some trouble building 2.4.x directly from svn.
> >
> > MacOS 10.14.6 (Mojave)
> >
> > $ autoconf -V
> > autoconf (GNU Autoconf) 2.69
> >
> > $ glibtool --version
> > glibtool (GNU libtool) 2.4.6
> > [ installed via "brew install libtool" ]
> >
> > $ cc --version
> > Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> >
> > After "svn checkout", I tried:
> >
> > $ ./configure
> >
> > - -bash: ./configure: No such file or directory
> >
> > $ ./buildconf --with-apr=/usr/local/Cellar/apr/1.7.0/bin/apr-1-config
> > [ output okay, a few "missing directory" warnings which INSTALL says
> > [no output, but now "configure" exists]
> >
> > $ ./configure
> > ./configure: line 2990: syntax error near unexpected token `Apache,'
> > ./configure: line 2990: `APR_ENABLE_LAYOUT(Apache, errordir iconsdir
> > htdocsdir cgidir)'
> >
> > I'm no expert in toolchains, so I'm not sure where to look next. Did I
> > do something wrong?
>

I note you mentioned apr 1.7.0. If you grab and pre build apr, and then
apr-util (and openssl and anything else you want to refresh) or install the
compiled system package, it should work. Point at them --with-apr plus
--with-aprutil.

I always use the --with-included-apr method where you extract apr to
> the srclib/ dir of your source tree.
> svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr
>

If you check out a 1.7.0 flavor of apr, be sure to also use
--with-included-aprutil and the latest aprutil 1.6.5 flavor checked out
into srclib/aprutil alongside any apr flavor 1.x. Jeff's suggestion above,
apr 2.0 (which has not been released) now combines aprutil into apr. Any of
these options should get you further.

Re: Odd vulnerabilities_24.html output

[William A Rowe Jr]

On Sat, Apr 4, 2020 at 11:27 AM William A Rowe Jr 
wrote:

> On Sat, Apr 4, 2020 at 10:23 AM Daniel Ruggeri 
> wrote:
>
>> Hi, all;
>>I'm not sure what mechanism is used to generate
>> https://httpd.apache.org/security/vulnerabilities_24.html from
>>
>> https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/vulnerabilities-httpd.xml
>> ,
>>
>
> https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl
>
>
>> an anomaly has been reported to me in response to the security
>> announcements from last release.
>>
>>For both CVE-2020-1934 and CVE-2020-1927, the source file says
>> "Apache HTTP Server versions 2.4.0 to 2.4.41" in the description, but
>> the rendered result is "Apache HTTP Server versions 2.4.0 to 2.41". If
>> anyone has pointers on how the site build happens, I can look into it
>> further.
>>
>
> Something in that xslt translation is treating the revision number
> numerically,
> and not as a string.
>

Looking close, it isn't clear why any version/numeric text handling should
occur
by the xslt that would lose the '.4' segment from any .xml within the
context of;
  

  
 
   

Tag attributes legitimately broken apart for version processing include;
  
  

(Those fixed date tags need fixing as well.)


>If it's too complicated a fix, I'm OK with removing that line from
>> the description. The CVE reports must include the version vulnerability
>> info in the description, but it's not really a requirement for the site
>> (I was just keeping them consistent).
>>
>
For our xml records, we derive that information as illustrated, so that
line was redundant. (Also note spelling, and these descriptions are much
more terse than the usual descriptions the project has provided.)
low: mod_proxy_ftp use of uninitialized value (CVE-2020-1934
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1934>)

Apache HTTP Server versions 2.4.0 to 2.41
mod_proxy_ftp use of uninitialized value with maliciosu FTP backend.

Acknowledgements: The issue was discovered by Chamal De Silva
Reported to security team 3rd January 2020
Issue public 1st April 2020
Affects 2.4.41, 2.4.40, 2.4.39, 2.4.38, 2.4.37, 2.4.35, 2.4.34, 2.4.33,
2.4.30, 2.4.29, 2.4.28, 2.4.27, 2.4.26, 2.4.25, 2.4.23, 2.4.20, 2.4.18,
2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2,
2.4.1, 2.4.0low: mod_rewrite CWE-601 open redirect (CVE-2020-1927
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1927>)

Apache HTTP Server versions 2.4.0 to 2.41
Some mod_rewrite configurations vulnerable to open redirect.

Acknowledgements: The issue was discovered by Fabrice Perez
Reported to security team 5th December 2019
Issue public 1st April 2020
Affects 2.4.41, 2.4.40, 2.4.39, 2.4.38, 2.4.37, 2.4.35, 2.4.34, 2.4.33,
2.4.30, 2.4.29, 2.4.28, 2.4.27, 2.4.26, 2.4.25, 2.4.23, 2.4.20, 2.4.18,
2.4.17, 2.4.16, 2.4.12, 2.4.10, 2.4.9, 2.4.7, 2.4.6, 2.4.4, 2.4.3, 2.4.2,
2.4.1, 2.4.0

Re: Odd vulnerabilities_24.html output

[William A Rowe Jr]

On Sat, Apr 4, 2020 at 10:23 AM Daniel Ruggeri  wrote:

> Hi, all;
>I'm not sure what mechanism is used to generate
> https://httpd.apache.org/security/vulnerabilities_24.html from
>
> https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/vulnerabilities-httpd.xml
> ,
>

https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl


> an anomaly has been reported to me in response to the security
> announcements from last release.
>
>For both CVE-2020-1934 and CVE-2020-1927, the source file says
> "Apache HTTP Server versions 2.4.0 to 2.4.41" in the description, but
> the rendered result is "Apache HTTP Server versions 2.4.0 to 2.41". If
> anyone has pointers on how the site build happens, I can look into it
> further.
>

Something in that xslt translation is treating the revision number
numerically,
and not as a string.


>If it's too complicated a fix, I'm OK with removing that line from
> the description. The CVE reports must include the version vulnerability
> info in the description, but it's not really a requirement for the site
> (I was just keeping them consistent).
>
> --
> Daniel Ruggeri
>
>

Re: [VOTE] Release httpd-2.4.43

[William A Rowe Jr]

On Mon, Mar 30, 2020 at 8:41 PM Jan Ehrhardt  wrote:

> William A Rowe Jr in gmane.comp.apache.devel (Mon, 30 Mar 2020 09:01:07
> -0500):
> >I'm making no attempt to build against the no-longer-supported msldap API
> >nor openldap which doesn't support building on windows.
>
> Maybe I am missing the point, but at least OpenLDAP 2.4.47 builds fine
> on Windows: https://github.com/winlibs/openldap
> OpenLDAP 2.4.49 is the newest version, but that version is only a year
> and a month newer the 2.4.47.
>

I'll research - I'd added openldap on a mostly experimental basis for use
on unix,
it isn't included by default on either unix or win32. If one doesn't
rebuild openldap
against the current openssl, these system openldap's dependency on the
system
openssl collides against current httpd/apr-util's openssl. Thanks for the
pointer.


> My own builds of httpd-2.4.43 link to the Windows system library
> wldap32.lib. I guess Apachelounge does the same for building
> apr_ldap-1.dll as part of apr-util 1.6.1.


Yup, wldap32 may not be supported by APR, but is still the default, and the
respective CMake defaults for win32 continue to utilize this from apr-util
1.6.1
and httpd-2.4.x. At one point I had an openldap based fork but only took
that
as far as openldap 2.3.x before I'd set that aside and rebased on the
projects'
default choices for windows.

Re: [VOTE] Release httpd-2.4.43

[William A Rowe Jr]

On Sun, Mar 29, 2020 at 8:26 AM Daniel Ruggeri  wrote:

> On 3/27/2020 12:58 PM, William A Rowe Jr wrote:
> > On Fri, Mar 27, 2020 at 12:34 PM Steffen  > <mailto:i...@apachelounge.com>> wrote:
> >
> > +1 All fine on Windows.
> >
> >
> > Your's are still the .dsp based builds, right? I can confirm also on
> > the CMake flavor.
>
> Thanks, Bill. Shall this response be considered a +1 for the purposes of
> the release vote?
>

Hi Daniel, I'm not a PMC member, just observing that in my *snapshot*
refresh
to https://github.com/appsuite/oss-httpd-build/  every component including
the
current apr/apr-util, httpd and all the rest of the third party components
are
successfully building, under CMake on Windows (those with cmake build
tooling
and the few others using their windows mak solutions) - and they should
continue
to do so in their next releases unless they are broken in the interim.

I'm making no attempt to build against the no-longer-supported msldap API
nor openldap which doesn't support building on windows.

So as a from-the-peanut-gallery observation, the state of 2.4.x branch at
the
time of this candidate are looking good on CMake (and mak files, per Gregg,
and I presume dsp/vcproj files, per Steffen.)

Re: OpenSSL 1.1.1e New EOF detection breaks session resumption

[William A Rowe Jr]

If you want to beat up your server in unusual ways, a good way to do this
is to
run it against https://www.ssllabs.com/ssltest/ from Qualsys with debug
logging
level throughout. I think you'll find we already sanitize all error results.



 On Fri, Mar 27, 2020 at 1:24 PM Steffen  wrote:

>
> A discussion started on Apachelounge about an possible issue with OpenSSL
> 1.1.1e ( https://www.apachelounge.com/viewtopic.php?p=38941#38941 )
>
> This is the introduced new EOF in 1.1.1e :
> https://github.com/openssl/openssl/commit/db943f43a60d1b5b1277e4b5317e8f288e7a0a3a
>
>
> Discussion on OpenSSL is at
> https://github.com/openssl/openssl/issues/11378
>
> I dot understand what is going on, but  Daniel Stenberg (Curl) states
> :  The "poorly-implemented HTTP/1.1 servers" are still out there and are
> being used. How common? Impossible to say.
>
>
> OpenSSL has a Patch with description :
>  ... possible application breakage caused by a change in behavior
> introduced in 1.1.1e.  It affects at least nginx, which logs error messages
> such as:
> nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error:
> 4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while
> keepalive, client: , server: [::]:443
>
> So looks  that nginx is effected.
>
> My question is :
> *Is Apache effected ? * Looks not, because till now: Apachelounge has
> more then a week 2.4.41 available with 1.1.1e, which is downloaded over
> 50.000 times and no issues reported like this.
>
> Steffen
>

Re: [VOTE] Release httpd-2.4.43

[William A Rowe Jr]

On Fri, Mar 27, 2020 at 12:34 PM Steffen  wrote:

> +1 All fine on Windows.
>

Your's are still the .dsp based builds, right? I can confirm also on the
CMake flavor.

Re: Help needed to test Windows builds in Travis

[William A Rowe Jr]

The  https://github.com/appsuite/oss-httpd-build/tree/master/mak tree
contains
all the tooling we've used to generate convenience binaries.
Makefile.build-win
should be what you are looking for; we no longer test .dsp/.mak based
builds,
only CMake logic. But testing both while they remain 'supported' is a very
wise
idea.



On Fri, Nov 8, 2019 at 12:56 AM Luca Toscano  wrote:

> Hi everybody,
>
> if you build httpd for Windows can you give us a list of commands and
> steps that you usually do? I am not familiar enough with the platform
> and [1] is still a bit cryptic to me :)
> The end goal is to add the build steps to our Travis config, to run
> them every time that a commit happens.
>
> Thanks in advance!
>
> Luca
>
> [1] https://httpd.apache.org/docs/2.4/platform/win_compiling.html
>

Re: httpd 2.4 and maintainer-mode

[William A Rowe Jr]

On Wed, Oct 9, 2019 at 3:42 PM Jim Jagielski  wrote:

> Just the issues w/ libxml comments:
>
> In file included from mod_xml2enc.c:38:
> In file included from /usr/local/include/libxml2/libxml/encoding.h:31:
> /usr/local/include/unicode/ucnv.h:1:1: error: // comments are not allowed
> in this language [-Werror,-Wcomment]
> // Copyright (C) 2016 and later: Unicode, Inc. and others.
>

Jim, are you missing
http://svn.apache.org/viewvc?view=revision=1867183
which you had already fixed the quirk on trunk/?  Seems that clang is being
a bit opaque
about it's identity and confounding the pragmas wrapping our libxml2.h
includes.

Re: Migrate to git?

[William A Rowe Jr]

On Wed, Oct 9, 2019, 07:59 Michal Karm  wrote:

> On 10/08/2019 10:44 AM, Greg Stein wrote:
> > On Tue, Oct 8, 2019 at 3:13 AM Joe Orton  > > wrote:
> >
> > On Sat, Oct 05, 2019 at 04:09:34PM -0400, Jim Jagielski wrote:
> > > Various PMCs have made their default/de-facto SCM git and have
> seen an
> > > increase in contributions and contributors...
> > >
> > > Is this something the httpd project should consider? Especially w/
> the
> > > foundation officially supporting Github, it seems like time to
> have a
> > > discussion about it, especially as we start thinking about the
> next 25
> > > years of this project :)
> >
> > Can we use Travis CI as well?  If so I am +1 on moving to github,
> being
> > able to easily configure a consistent CI across branches and PRs
> will be
> > a major improvement over the status quo.  (I have no idea how
> buildbot
> > works or how to improve it and it's unusuable before commits)
> >
> >
> > Travis CI is possible *today* ... since the svn commits are replicated
> over to
> > github, Travis can pick them up and run tests. Just file an INFRA ticket
> to
> > enable it.
> >
> > Cheers,
> > -g
> >
> Hi Greg,
>
> That does not cover Joe's note "...and PRs...". Basically having a
> transparent,
> dead simple set of gate smoke tests
> on a handful of major platforms and config flavours/layouts. Linux and
> Windows
> can be used in this capacity for free (as in free beer).
>
> It makes almost no sense unless all committers agree that all code commits
> pass
> through PR gate, i.e.
> no direct commits.
>

This approach implies a test driven codebase, where every exception to
deliberate behavior at the functional level is called out by the test
schema.

That doesn't describe the scope of our test-framework, which consists only
of behavioral run-time testing against a small and discrete list of
expectations. No automated testing will substitute at this particular
project for attentive code review, although it would be very kind to run
all PR's through a compile validation for the benefit of the submitter and
reviewers.

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

[William A Rowe Jr]

On Fri, Sep 27, 2019 at 10:48 AM Eric Covener  wrote:

> On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek
>  wrote:
> >
> > On 2019-09-27 03:00, Stefan Eissing wrote:
> > > I know of no plans to implement HTTP/3 support in Apache httpd.
> >
> > I'm sorry, but this seems rather strange to me. So what's the idea
> behind this
> > decision (or better said the lack of a plan)?
>

It's helpful to understand the nature of the ASF. We are always an incubator
of great solutions written in code. But there is no ombudsman, no dictates
which direct projects to do X, Y or Z when it comes to the code that our
projects create. No demands of implementing features, etc. Everything that
someone steps up to offer end up right here for discussion on dev@.

There is no planning cabul, or even budget to put this on some coders
to accomplish. You certainly can add an enhancement request on our
bugzilla tracker to suggest this, but it is on some motivated party to bring
the development effort to the table.


> HTTP/3 would be a lot of work, a lot of shoehorning into HTTPD, and
> likely be de-stabilizing for quite some time.   There is
> simply nobody (seemingly) working on it.
>


> HTTPD is great and familiar to lots of people, but HTTPD'S age brings
> a lot of baggage. Lots of other great servers have much
> less baggage and currently have much more commercial interest and buzz.
>

And it is engineered as an http/1 server. While we can now (with all props
to Stefan and Tatsuhiro) claim http/2, we don't have the framework to really
offer great h2 push support and other architecture required for long-lived
dynamic request pipelines. http/2 and http/3 offer server-originated
transactions that httpd never anticipated. That would be an entirely new
module which both mod_http2 and mod_http3 would want to build on,
and an entirely new definition of the CGI spec and related modules.

So we "speak" http/2 now, and might speak http/3 sooner or later with
Google's quiche or some other provider. But the server isn't constructed
to be attentive to both the client's traffic demands and the backend's
desire to push unsolicited traffic. That would be a fun chasm for some
coders to jump, and we would welcome them here.

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

[William A Rowe Jr]

This answer \V/ (from Stefan) below. More explanation follows...

The httpd project is entirely transparent. All development decisions occur
on the email
list you asked this question. Stefan himself stepped up to integrate
Tatsuhiro's nghttp2
implementation into httpd (very successfully) so we have mod_http2 as a
core module.

Something similar may happen where someone creates a mod_quic (google
obviously
hasn't shared such a thing, according to google search) or someone
integrates the
readily available implementations. We'll see, the Apache HTTP Server
project is very
welcoming of new community members who offer innovations like this (again
using
the example of Stefan, who quickly became a committer and PMC member after
bringing the mod_h2 proposal to the project.)

The troublesome part is that both HTTP/2 and HTTP/3 get ahead of their skis
by
being L4-L7 protocols, where HTTP/1 is L7. The httpd server was designed to
be
an OSI Layer 7 component. Stefan's done some great work breaking that design
model to have mod_http2 "fit" right in, but it's an uneasy fit.

Now HTTP/3 offers some very serious advantages, and the project was offered
some fun HTTP-over-UDP transport work over a decade ago. But any HTTP3/quic
component swaps out tls+mod_ssl+http+http2 work for an new and better
approach
to TLS  handshake negotiation and transport. It's going to be a fun
development
project for someone perhaps.

AFAIK no-one has expressed interest. But to anyone who has an interest, even
if you want to take such a project online, please share with dev@httpd that
you
are chasing the idea and maybe you'll find a great collaborator or few to
bring
a great proposal back to the project, once you decide it's ready for
submission.

Cheers,

Bill




On Fri, Sep 27, 2019 at 2:00 AM Stefan Eissing 
wrote:

> I know of no plans to implement HTTP/3 support in Apache httpd.
>
> > Am 26.09.2019 um 19:54 schrieb Alex Hautequest :
> >
> >
> https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support
> >
> > With that, the obvious question: what about Apache?
>
>

Re: Problem w/ Revision 1864435

[William A Rowe Jr]

This commit somehow missed my inbox (and wasn't quoted in your observations)

http://svn.apache.org/viewvc?view=revision=1864435

Rainer, you observed in the commit notes;

The GCC flag "-Wno-error=comment" introduced by r1855446

and r1850745 
are only known since GCC 4.2. Since it gets
set unconditionally, this breaks compilation with old GCC
even when not using maintainer mode.

Make the fix for maintainer mode more specific by using
a version dependent pragma in the relevant two C files
only switching off error status for comment warnings.

Can we read this to say the comment error wasn't thrown by GCC 4.1 and
earlier?

Can we please revert, and add an autoconf test for the support of (or lack
of errors against) this -Wno-error=comment flag? That should allow us to
apply it to all friendly compilers and avoid adding it to other elder
compilers.




On Thu, Sep 19, 2019 at 10:26 AM Jim Jagielski  wrote:

> This breaks building on macOS:
>
> Making all in filters
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o libmod_data.la
> mod_data.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_ratelimit.la mod_ratelimit.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_reqtimeout.la mod_reqtimeout.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_ext_filter.la mod_ext_filter.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_request.la mod_request.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_include.la mod_include.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_filter.la mod_filter.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -g -O0 -static  -o
> libmod_reflector.la mod_reflector.lo
> /Users/jim/src/asf/code/dev/httpd-trunk/srclib/apr/libtool --silent
> --mode=link gcc -I/usr/local/include/libxml2 -I/usr/local/include -Wall
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -std=c89
> -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement 

Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)

[William A Rowe Jr]

Lifting a post from the users discussion list. Should we revisit the error
responses
we make to demanding SSLRequireSSL, requiring SNI hostname matching, etc
as 400 protocol violations, rather than "Permission Denied" with no further
explanations?

On Fri, Sep 13, 2019 at 8:25 AM William A Rowe Jr 
wrote:

> On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer  wrote:
>
>>
>> On 2019-09-13 14:50, William A Rowe Jr wrote:
>>
>> > The same would likely apply to ssl traffic abuse. At this late date,
>> > clients connecting with 20 year old ssl semantics doesn't seem
>> > noteworthy.
>>
>> SNI-support does not exist in some 3rd party services, like Sucuri etc.,
>> so it's sadly a very real thing in 2019 as well.
>>
>> The "problem" is that a 403 is logged in this case, but no accompanied
>> reason is logged in the ErrorLog, making it very hard to debug.
>>
>
> Services that don't speak modern TLS are certainly a real thing. Ignoring
> them isn't unreasonable. TLS 1.0 and 1.1 were deprecated a year ago
> and they do disappear mid-2020.
>
> I'd agree this is confusing. Asking operators to set loglevel debug (heck,
> in this case even loglevel info would suffice) is the very very very first
> step to debug any problem behavior in httpd, increasing the signal
> strength of errors outside of the operators control disturbs the other
> 99% of operators who've got this.
>
> Would we agree that the correct error response to any TLS handshake
> omission simply be a 400 error, and not an error that indicates some
> authnz configuration trouble? Does that make it more obvious that the
> error log needs to be inspected at info, or debug level?
>
> A 426 response would seem to be appropriate for TLS 1.0/1.1 but it
> doesn't have the granularity to ask that a legit TLS 1.2 connection
> missing SNI needs to upgrade. Seems 400 might be best.
>
> On Fri, Sep 13, 2019 at 11:48 AM Tom Sommer  wrote:

>
> I think this is a great idea and compromise.
>
>
> ---
> Tom



>
>
>

Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)

[William A Rowe Jr]

On Fri, Sep 13, 2019 at 7:55 AM Tom Sommer  wrote:

>
> On 2019-09-13 14:50, William A Rowe Jr wrote:
>
> > The same would likely apply to ssl traffic abuse. At this late date,
> > clients connecting with 20 year old ssl semantics doesn't seem
> > noteworthy.
>
> SNI-support does not exist in some 3rd party services, like Sucuri etc.,
> so it's sadly a very real thing in 2019 as well.
>
> The "problem" is that a 403 is logged in this case, but no accompanied
> reason is logged in the ErrorLog, making it very hard to debug.
>

Services that don't speak modern TLS are certainly a real thing. Ignoring
them isn't unreasonable. TLS 1.0 and 1.1 were deprecated a year ago
and they do disappear mid-2020.

I'd agree this is confusing. Asking operators to set loglevel debug (heck,
in this case even loglevel info would suffice) is the very very very first
step to debug any problem behavior in httpd, increasing the signal
strength of errors outside of the operators control disturbs the other
99% of operators who've got this.

Would we agree that the correct error response to any TLS handshake
omission simply be a 400 error, and not an error that indicates some
authnz configuration trouble? Does that make it more obvious that the
error log needs to be inspected at info, or debug level?

A 426 response would seem to be appropriate for TLS 1.0/1.1 but it
doesn't have the granularity to ask that a legit TLS 1.2 connection
missing SNI needs to upgrade. Seems 400 might be best.

Re: SNI strict error logged as ssl:info, should be ssl:warm? (r1841455)

[William A Rowe Jr]

When we started rejecting more invalid traffic, e.g. malformed http request
and header lines, we downgraded that all for plaintext traffic since there
is no reason to collect garbage traffic reports in the normal error logging
scenario.

The same would likely apply to ssl traffic abuse. At this late date,
clients connecting with 20 year old ssl semantics doesn't seem noteworthy.

Info exists to attempt to record a single point of failure on each
transaction. Debug is for finer granularity. Warn is for correcting things
that the *operator has control over* and can rectify.

The operator has no control over what clients connect to the server, not
the request they present, so handshake issues never belong at loglevel warn
IMO.



On Fri, Sep 13, 2019, 06:49 Tom Sommer  wrote:

>
> On 2019-09-13 13:40, Tom Sommer wrote:
>
> > Would it not make sense to change this to APLOG_WARN? It used to be
> > APLOG_ERR, which made more sense than APLOG_INFO/APLOG_DEBUG?
>
> Here is the change from ERR to DEBUG/INFO:
> https://svn.apache.org/viewvc?view=revision=1841446
>
> ---
> Tom
>

Re: Trouble building 2.4.41 on Windows with CMake

[William A Rowe Jr]

Thanks for the additional eyeballs and testing!

I'm working up a CI for release/asf release candidates/snapshot (across
all of our dependencies' development chains)... will share when I'm a bit
closer to the goalpost. I'm happy to add the github-based mod_h2/_md
"external" modules as well to that CI exam.



On Fri, Aug 30, 2019 at 12:10 PM Steve Hay 
wrote:

> I've tried the build again with the proper fix in place and all is well
> for me: mod_md now reports three missing prereqs:
>
> -- mod_md was requested but couldn't be built due to a missing
> prerequisite (OPENSSL_FOUND)
> -- mod_md was requested but couldn't be built due to a missing
> prerequisite (CURL_FOUND)
> -- mod_md was requested but couldn't be built due to a missing
> prerequisite (JANSSON_FOUND)
>
> The complete cmake output is attached in case it is of interest. This was
> using 3.15.2 - the latest version.
>
> Thanks for fixing this.
>
>
> On Fri, 30 Aug 2019 at 09:32, William A Rowe Jr 
> wrote:
>
>> However, it fixed it by ignoring most of the troubles... I have my IP
>> unblocked,
>> so I'm able to get some further fixes in, I added the iterator, confirmed
>> the
>> newest fixes and have committed to trunk and 2.4.x. Steve, please retest
>> and
>> report back?
>>
>> There is no such thing as a _102 openssl result macro, that was a big
>> whoops,
>> since we never tested for that. And won't need to, ever again... deleted
>> the
>> openssl rev test (who would build such an unsupported ancient thing
>> anyways?
>> Shame on them.) And immediately failed on curl and jansson but for two
>> different
>> reasons - reminding us that copy-paste isn't always our friend.
>>
>> cmake has *long* had a FIND_PACKAGE for curl. Not so much for jansson.
>> But we didn't follow the missing logic for jansson or for curl, and
>> didn't invoke
>> the find facility for curl, so both were AWOL. Didn't matter with my
>> hack, since
>> we didn't look for them to be found, and the way I build, all the libs
>> and includes
>> are found during the compilation at the anticipated paths... all but the
>> libcurl_imp.lib which the existing cmake logic overlooked. Easily
>> hardcoded as;
>> cmake $(CMAKE_DEFAULTS)
>> -D CMAKE_INSTALL_PREFIX=$(DESTDIR) \
>> -D CURL_LIBRARIES=$(DESTDIR)/lib/libcurl_imp.lib
>>
>> The lesson in this is that there is more to script than what was copied,
>> it was no different than asking configure.in to work given only half the
>> necessary lines of configure script, and there are one of two different
>> patterns that must be followed; either a FIND_PACKAGE implementation
>> is available in common flavors of cmake for a specific package, or is not.
>> I guess the ask is not to commit untested build changes, well at least
>> don't backport them.
>>
>> The current state of CMake against 3.14 carries the following warnings,
>> I may or may not get around to addressing some or all of these, if anyone
>> else is looking for some low hanging fruit...
>>
>>
>> CMake Warning (dev) at CMakeLists.txt:563 (ELSEIF):
>>   Policy CMP0054 is not set: Only interpret if() arguments as variables or
>>   keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
>>   details.  Use the cmake_policy command to set the policy and suppress
>> this
>>   warning.
>>
>>   Quoted variables like "i" will no longer be dereferenced when the
>> policy is
>>   set to NEW.  Since the policy is not set the OLD behavior will be used.
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at CMakeLists.txt:615 (GET_TARGET_PROPERTY):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>> cmake_policy
>>   command to set the policy and suppress this warning.
>>
>>   The LOCATION property should not be read from target "gen_test_char".
>> Use
>>   the target name directly with add_custom_command, or use the generator
>>   expression $, as appropriate.
>>
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at CMakeLists.txt:120 (ELSEIF):
>>   Policy CMP0054 is not set: Only interpret if() arguments as variables or
>>   keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
>>   details.  Use the cmake_policy command to set the policy and suppress
>> this
>>   warning.
>>
>>   Quoted vari

Re: Trouble building 2.4.41 on Windows with CMake

[William A Rowe Jr]

However, it fixed it by ignoring most of the troubles... I have my IP
unblocked,
so I'm able to get some further fixes in, I added the iterator, confirmed
the
newest fixes and have committed to trunk and 2.4.x. Steve, please retest and
report back?

There is no such thing as a _102 openssl result macro, that was a big
whoops,
since we never tested for that. And won't need to, ever again... deleted
the
openssl rev test (who would build such an unsupported ancient thing anyways?
Shame on them.) And immediately failed on curl and jansson but for two
different
reasons - reminding us that copy-paste isn't always our friend.

cmake has *long* had a FIND_PACKAGE for curl. Not so much for jansson.
But we didn't follow the missing logic for jansson or for curl, and didn't
invoke
the find facility for curl, so both were AWOL. Didn't matter with my hack,
since
we didn't look for them to be found, and the way I build, all the libs and
includes
are found during the compilation at the anticipated paths... all but the
libcurl_imp.lib which the existing cmake logic overlooked. Easily hardcoded
as;
cmake $(CMAKE_DEFAULTS)
-D CMAKE_INSTALL_PREFIX=$(DESTDIR) \
-D CURL_LIBRARIES=$(DESTDIR)/lib/libcurl_imp.lib

The lesson in this is that there is more to script than what was copied,
it was no different than asking configure.in to work given only half the
necessary lines of configure script, and there are one of two different
patterns that must be followed; either a FIND_PACKAGE implementation
is available in common flavors of cmake for a specific package, or is not.
I guess the ask is not to commit untested build changes, well at least
don't backport them.

The current state of CMake against 3.14 carries the following warnings,
I may or may not get around to addressing some or all of these, if anyone
else is looking for some low hanging fruit...


CMake Warning (dev) at CMakeLists.txt:563 (ELSEIF):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "i" will no longer be dereferenced when the policy
is
  set to NEW.  Since the policy is not set the OLD behavior will be used.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:615 (GET_TARGET_PROPERTY):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the
cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target "gen_test_char".  Use
  the target name directly with add_custom_command, or use the generator
  expression $, as appropriate.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:120 (ELSEIF):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "i" will no longer be dereferenced when the policy
is
  set to NEW.  Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
  CMakeLists.txt:757 (GET_MOD_ENABLE_RANK)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:766 (IF):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "APR_HAS_LDAP" will no longer be dereferenced when
  the policy is set to NEW.  Since the policy is not set the OLD behavior
  will be used.
This warning is for project developers.  Use -Wno-dev to suppress it.









On Fri, Aug 30, 2019 at 2:24 AM Steve Hay 
wrote:

> Thanks to you both - that was indeed the trouble, and the fix has
> sorted it out for me.
>
> On Fri, 30 Aug 2019 at 08:16, Stefan Eissing
>  wrote:
> >
> > Added to trunk in r1866119.
> > Merged to 2.4.x in r1866121.
> >
> > Thanks for this, Bill!
> >
> > > Am 29.08.2019 um 19:05 schrieb William A Rowe Jr  >:
> > >
> > > Index: httpd-2.x/CMakeLists.txt
> > > ===
> > > --- httpd-2.x/CMakeLists.txt  (revision 1866089)
> > > +++ httpd-2.x/CMakeLists.txt  (working copy)
> > > @@ -508,7 +508,9 @@
> > >modules/lua/lua_vmprep.c   modules/lua/lua_dbd.c
> > >  )
> > >  SET(mod_lua_requires LUA51_FOUND)
> >

Re: Trouble building 2.4.41 on Windows with CMake

[William A Rowe Jr]

I have the immediate fix, can commit after lunch.

The *right* fix is to iterate over the _require'ments list, I just took the
shortcut of reducing this list to cmake (one of the most recent additions.)
That patch will take a bit longer.



On Thu, Aug 29, 2019 at 7:50 AM Stefan Eissing 
wrote:

> Please have a look at:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63672
>
> I think this is what you are seeing. We seem to be still looking for the
> cmake file that works well in all cases.
>
> > Am 29.08.2019 um 14:31 schrieb Steve Hay :
> >
> > I'm getting errors about missing prerequisites when building
> > httpd-2.4.41 on Windows using CMake (version 3.15.2).
> >
> > The modules in question are all optional so should simply be skipped
> > rather than stopping the build (I'm building with -DENABLE_MODULES=a),
> > but CMake is giving me an error:
> >
> > CMake Error at CMakeLists.txt:770 (IF):
> >  if given arguments:
> >
> >"NOT" "OPENSSL_FOUND" "CURL_FOUND" "JANSSON_FOUND"
> > "HAVE_OPENSSL_102" "STREQUAL" ""
> >
> >  Unknown arguments specified
> >
> > Building with the same command-line worked fine in 2.4.39:
> >
> > cmake -DCMAKE_INSTALL_PREFIX=D:\Dev\Temp\mp2\apache -G "NMake
> > Makefiles" -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_MODULES=a
> >
> > Output is attached.
> >
> > Any ideas what is going wrong here?
> > 
>
>

Breakage in httpd 2.4.39/windows/cmake?

[William A Rowe Jr]

Because of some trouble on another project, I wanted to recheck
the current nghttp2 build between our mutual dependencies and
httpd... and something isn't looking so healthy in the CMake
build of the last release. (But I did answer my question, bazel
shouldn't be failing to build nghttp2, it is rock hard stable in terms
of building rev 1.39.1) CMake is rev 3.9.4 in this example of our
build below.

Just as an aside this is all a byproduct of the mak/Makefile.build-win
script of https://github.com/appsuite/oss-httpd-build if anyone wants
to replicate. Sadly, the gather and preconfig steps still require WSU
- some unix on top of Windows for a bash environment. But that
build-win nmake logic is what gets us to this...

cd httpd-2.4.39 &&  cmake -G "NMake Makefiles" -D
CMAKE_BUILD_TYPE=RelWithDebInfo -D CMAKE_COLOR_MAKEFILE=OFF  -D
CMAKE_INSTALL_PREFIX=C:\Users\wrowe\dev\oss-httpd-build\dst\httpd-2.4.39-today
 C:\Users\wrowe\dev\oss-httpd-build\src/httpd-2.4.39 &&  cd ..
-- The C compiler identification is MSVC 19.11.25547.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Enterprise/VC/Tools/MSVC/14.11.25503/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Enterprise/VC/Tools/MSVC/14.11.25503/bin/Hostx64/x64/cl.exe --
works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found LibXml2:
C:/Users/wrowe/dev/oss-httpd-build/dst/httpd-2.4.39-today/lib/libxml2.lib
(found version "2.9.9")
-- Found Lua51:
C:/Users/wrowe/dev/oss-httpd-build/dst/httpd-2.4.39-today/lib/lua.lib
-- Found OpenSSL:
C:/Users/wrowe/dev/oss-httpd-build/dst/httpd-2.4.39-today/lib/libcrypto.lib
(found version "1.1.1c")
-- Found ZLIB:
C:/Users/wrowe/dev/oss-httpd-build/dst/httpd-2.4.39-today/lib/zlib.lib
(found version "1.2.11")
-- Looking for APR_HAS_XLATE
-- Looking for APR_HAS_XLATE - found
-- Performing Test APR_HAS_XLATE
-- Performing Test APR_HAS_XLATE - Failed
-- Looking for APU_HAVE_CRYPTO
-- Looking for APU_HAVE_CRYPTO - found
-- Performing Test APU_HAVE_CRYPTO
-- Performing Test APU_HAVE_CRYPTO - Success
-- Performing Test APR_HAS_LDAP
-- Performing Test APR_HAS_LDAP - Success
--
-- Summary of feature detection:
--
-- LIBXML2_FOUND  : TRUE
-- LUA51_FOUND .. : TRUE
-- NGHTTP2_FOUND  : TRUE
-- OPENSSL_FOUND  : TRUE
-- ZLIB_FOUND ... : TRUE
-- BROTLI_FOUND . : TRUE
-- APR_HAS_LDAP . : TRUE
-- APR_HAS_XLATE  : FALSE
-- APU_HAVE_CRYPTO .. : TRUE
--
CMake Warning (dev) at CMakeLists.txt:520 (ELSEIF):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "i" will no longer be dereferenced when the policy
is
  set to NEW.  Since the policy is not set the OLD behavior will be used.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:572 (GET_TARGET_PROPERTY):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the
cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target "gen_test_char".  Use
  the target name directly with add_custom_command, or use the generator
  expression $, as appropriate.

This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:111 (ELSEIF):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "i" will no longer be dereferenced when the policy
is
  set to NEW.  Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
  CMakeLists.txt:713 (GET_MOD_ENABLE_RANK)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- mod_charset_lite was requested but couldn't be built due to a missing
prerequisite (APR_HAS_XLATE)
--
--
-- Apache httpd configuration summary:
--
--   Build type .. : RelWithDebInfo
--   Install .pdb (if available).. : ON
--   Install manual .. : ON
--   Install prefix .. :
C:/Users/wrowe/dev/oss-httpd-build/dst/httpd-2.4.39-today
--   C compiler .. : C:/Program Files (x86)/Microsoft
Visual
Studio/2017/Enterprise/VC/Tools/MSVC/14.11.25503/bin/Hostx64/x64/cl.exe
--   APR include directory ... :
C:/Users/wrowe/dev/oss-httpd-build/dst/httpd-2.4.39-today/include
--   APR libraries ... :

Re: Default log file locations

[William A Rowe Jr]

On Thu, Jun 27, 2019 at 4:24 PM Eric Covener  wrote:

> > From my perspective it would be advantageous to have Apache write to
> > the terminal by default (i.e. no hardcoded log file locations) and
> > allow to override this behavior via the Apache configuration file.
>
> > Is there any reason why the default behavior is not that way yet?
>
> I think it's useful as opt-in, but I wouldn't want to see any
> "defaults" changed (whether that's how the code behaves in the absence
> of logging related directives, or how our default httpd.conf looks)
>
> One wrinkle I recall here is that the closing of stdout and stderr
> happens in APR (apr_proc_detach?) and it requires a new APR release to
> provide any alternate options there.
>

If you look at the -e argument to httpd binary, you'll see that we had to
offer
an alternative for those who didn't have access to / weren't satisfied with
the
Windows Event Log as an early/pre-ErrorLog error emits.

Perhaps -e can be applied to Unix as well, and that some argument such as
'-' can be understood to mean stderr?

Re: AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[William A Rowe Jr]

On Thu, Jun 27, 2019 at 2:06 PM Ruediger Pluem  wrote:

>
> On 06/25/2019 10:39 AM, Plüm, Rüdiger, Vodafone Group wrote:
> >
> > Another related question: Do you think it would be beneficial if we
> replace
> > the apr_psprintf with apr_pstrcat in props.c as long as they only concat
> strings without
> > further formatting?
>
> Anyone any opinion on this?
>

I would expect apr_pstrcat to be more performant, wise change.

Re: svn commit: r1861542 - in /httpd/httpd/trunk: docs/manual/mod/mod_alias.xml modules/mappers/mod_alias.c

[William A Rowe Jr]

Hi Eric,

Looking at this feature, and the new allowance effective June 2014,
is this something we would want to toggle by envvar (in addition to
or in lieu of a directive) similar to various gzip, caching, downgrade
and particularly the redirect-carefully overrides? This seems like
the sort of feature to dodge for older unsuspecting clients based
on browsermatch, once the exceptions are identified;

https://httpd.apache.org/docs/2.4/env.html#special



On Mon, Jun 17, 2019 at 1:35 PM  wrote:

> Author: covener
> Date: Mon Jun 17 18:35:24 2019
> New Revision: 1861542
>
> URL: http://svn.apache.org/viewvc?rev=1861542=rev
> Log:
> add RedirectRelative directive to allow relative Redirect targets
>
> 2616 forbade relative redirect URLs, but 7231 allows them
> Early 2.2 maintenance levels did not fix them up, but later 2.2 and all 2.4
> fixed them up with ap_construct_url().
>
> Allow opt-in to not fixing up relative URLs with RedirectRelative
>
>
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/mod_alias.xml
> httpd/httpd/trunk/modules/mappers/mod_alias.c
>
> Modified: httpd/httpd/trunk/docs/manual/mod/mod_alias.xml
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_alias.xml?rev=1861542=1861541=1861542=diff
>
> ==
> --- httpd/httpd/trunk/docs/manual/mod/mod_alias.xml (original)
> +++ httpd/httpd/trunk/docs/manual/mod/mod_alias.xml Mon Jun 17 18:35:24
> 2019
> @@ -621,4 +621,25 @@ ScriptAliasMatch "(?i)^/cgi-bin(.*)" "/u
>  
>  
>
> +
> +RedirectRelative
> +Allows relative redirect targets.
> +RedirectRelative OFF|ON
> +RedirectRelative OFF
> +server configvirtual
> host
> +directory
> +2.5.1 and later
> +
> +
> +
> +By default, if the target URL of a Redirect
> +directive is a relative URL beginning with a '/' character, the
> server
> +converts it to a an absolute URL before responding to the client. By
> +setting RedirectRelative to the value "ON",
> +the relative URL is presented to the client directly.
> +
> +
> +
> +
> +
>  
>
> Modified: httpd/httpd/trunk/modules/mappers/mod_alias.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_alias.c?rev=1861542=1861541=1861542=diff
>
> ==
> --- httpd/httpd/trunk/modules/mappers/mod_alias.c (original)
> +++ httpd/httpd/trunk/modules/mappers/mod_alias.c Mon Jun 17 18:35:24 2019
> @@ -37,6 +37,10 @@
>  #include "ap_expr.h"
>
>
> +#define ALIAS_FLAG_DEFAULT -1
> +#define ALIAS_FLAG_OFF 0
> +#define ALIAS_FLAG_ON  1
> +
>  typedef struct {
>  const char *real;
>  const char *fake;
> @@ -58,6 +62,7 @@ typedef struct {
>  char *handler;
>  const ap_expr_info_t *redirect;
>  int redirect_status;/* 301, 302, 303, 410, etc */
> +int allow_relative; /* skip ap_construct_url() */
>  } alias_dir_conf;
>
>  module AP_MODULE_DECLARE_DATA alias_module;
> @@ -80,6 +85,7 @@ static void *create_alias_dir_config(apr
>  alias_dir_conf *a =
>  (alias_dir_conf *) apr_pcalloc(p, sizeof(alias_dir_conf));
>  a->redirects = apr_array_make(p, 2, sizeof(alias_entry));
> +a->allow_relative = ALIAS_FLAG_DEFAULT;
>  return a;
>  }
>
> @@ -111,7 +117,9 @@ static void *merge_alias_dir_config(apr_
>  a->redirect = (overrides->redirect_set == 0) ? base->redirect :
> overrides->redirect;
>  a->redirect_status = (overrides->redirect_set == 0) ?
> base->redirect_status : overrides->redirect_status;
>  a->redirect_set = overrides->redirect_set || base->redirect_set;
> -
> +a->allow_relative = (overrides->allow_relative != ALIAS_FLAG_DEFAULT)
> +  ? overrides->allow_relative
> +  : base->allow_relative;
>  return a;
>  }
>
> @@ -591,31 +599,33 @@ static int translate_alias_redir(request
>  if (ret == PREGSUB_ERROR)
>  return HTTP_INTERNAL_SERVER_ERROR;
>  if (ap_is_HTTP_REDIRECT(status)) {
> -if (ret[0] == '/') {
> -char *orig_target = ret;
> -
> -ret = ap_construct_url(r->pool, ret, r);
> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
> APLOGNO(00673)
> -  "incomplete redirection target of '%s' for "
> -  "URI '%s' modified to '%s'",
> -  orig_target, r->uri, ret);
> -}
> -if (!ap_is_url(ret)) {
> -status = HTTP_INTERNAL_SERVER_ERROR;
> -ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00674)
> -  "cannot redirect '%s' to '%s'; "
> -  "target is not a valid absoluteURI or
> abs_path",
> -  r->uri, ret);
> -}
> -else {
> -/* append requested query only, if the config 

Re: How can I dive into apache webserver source code

[William A Rowe Jr]

I'm confused, why are you building with gcc to a Microsoft OS platform
target?

What you are left with is a hybrid of bad posix-like thunks to native MS
API.

You COULD install SFU (the Ubuntu-on-Windows layer) and have a true
posix environment, but be warned I'm seeing broken locking behavior relative
to Linux/BSD that I haven't found an explanation to, just yet. I'd encourage
you to try this and use gdb/eclipse.

Or you could simply build under VC for win32 using the project files or
using
CMake and have something we all test against, which uses the win32 API.

Myself, trying to debug on Win32, I use the project files, update them using
Apache.dsw and let all the updates happen for the modern VisualStudio,
and from that environment, choose my invocation runtime line and dive in
pretty much from the build environment. It's helpful to know the -X option,
which disables spawning a child and ensures you are looking at the entire
execution environment in a single process. Setting breakpoints, etc becomes
trivial.




On Mon, Apr 22, 2019 at 8:53 AM Navjot Singh 
wrote:

> How can I debug Apache http webserver source code? I've always done is the
> following:
>
> My System details are as follows
>
> Operating system: Window 10
>
> compiler: gcc(MinGw)
>
> bits: 64 bits
>
> Open multiple copies of my editor (Visual Studio/Eclipse/Whatever) and
> then debug and do line breaks step through the code. Find out the flow of
> the code, stack trace through to see where the key points are and go from
> there.
>
> I can look at method after method - but it's nice if I can click on
> something and then see where in the code it's executed and follow along.
> Let's me get a feel for how the developer wanted things to work.
>
> *How can i debug Apache http webserver source code? I would love to hear
> any improvements you can suggest to this post?*
>

HTTP Protocol workshop notes

[William A Rowe Jr]

On Tue, Apr 9, 2019 at 11:48 AM Roy T. Fielding  wrote:

> > On Apr 9, 2019, at 3:30 AM, Stefan Eissing 
> wrote:
> >
> > I just did some tests with https://redbot.org/ (the site tester by Mark
> Nottingham) against our server and it notifies of 2 things:
> >
> > 1. The "Keep-Alive" header is deprecated. I tried to "Header unset
> Keep-Alive" but that has no effect. Seems to be added very late.
> >   Do we have a way to suppress it?
>
> Please hold off on that one.  We received several requests that it not be
> deprecated
> because the information that Apache sends is useful for avoiding request
> loss when
> the max is reached.
>

Speaking of external requests and HTTP interests, as usual Daniel has done
a very good job summarizing this year's workshop that Stefan had brought to
our attention a number times;

https://daniel.haxx.se/blog/2019/04/02/the-http-workshop-2019-begins/
https://daniel.haxx.se/blog/2019/04/04/more-amsterdamned-workshop/
https://daniel.haxx.se/blog/2019/04/04/workshop-season-4-finale/

Worth a skim.

Re: http://svn.apache.org/r1850745

[William A Rowe Jr]

To take this discussion all the way back to APR project's potential
concerns...

On Wed, Mar 13, 2019 at 8:03 AM Jim Jagielski  wrote:
>
> > On Mar 13, 2019, at 8:56 AM, Nick Kew  wrote:
> >
> >> On 13 Mar 2019, at 12:43, Jim Jagielski  wrote:
> >>
> >> Is there anyone else building 2.4 on macOS under maintainer-mode
> >> who is also being affected by the above? The fact that I seem to
> >> be the anyone "complaining" :) seems weird...
> >
> > Just out of interest, is that with a libxml2-enabled APR version?
> > Guess I need to test-drive that on Mac/latest, which has bitten me
> > on similar platform issues before now!
>
> It's libxml2 from MacPorts... which is basically vanilla libxml2.
>
> APR is 1.6.x

Here's the concern Nick raises... apr 2.0 (and now apr-util 1.7) allow us
to substitute --with-libxml2 in place of expat. This works for most
scenarios (subversion itself still needs expat specifically, since it uses
more than simple apr_xml.)

It would be good to also fix maintainer mode in apr 1.7.0, along with the
OSX quirk in APR_OFF_T_FMT, so we are prepared for the apr-util 1.7.0
libxml2 Nick has just backported. This same compiler emit on OSX should
rise again in this scenario, *except* that in apr we don't toggle -std=c89.
So perhaps we will observe no warnings, if clang defaults to a later -std=
option?

I'd like (speaking from APR's perspective) to find the right solution to
this bogus combination of OSX clang 5 comment rules and their icu library
includes. And we presume that is going to happen again with some other
system headers down the road.

Here's what happens today using libxml2 on httpd;

On Wed, Mar 13, 2019 at 8:04 AM Jim Jagielski  wrote:
>
> > On Wed, Mar 13, 2019 at 1:45 PM Eric Covener  wrote:
> >>
> >> On Wed, Mar 13, 2019 at 8:43 AM Jim Jagielski  wrote:
> >>>
> >>> Is there anyone else building 2.4 on macOS under maintainer-mode
> >>> who is also being affected by the above? The fact that I seem to
> >>> be the anyone "complaining" :) seems weird...
> >>
> >> FWIW Looks like I have maintainer mode but not libxml2
>
> Yeah, I also think it depends on the version of clang... previous
versions did not flag
>
> /usr/local/include/unicode/uenum.h:1:1: error: // comments are not
allowed in this language [-Werror,-Wcomment]
>
> as fatal errors.

To solve for the case of --with-maintainer-mode for APR + APR-UTIL 1.7
releases, I see three possibilities;

  Only for maintainer mode, where we are strictly handling all errors,
always
  check all -std=c99 behaviors (fix any legacy pre-c99 issues that may
arise.)
  All the system headers using c99 (or earlier) semantics should behave
well.
  I'm expecting we still adhere to c89, especially in all APR 1.x releases,
but
  we don't need to explicitly add that flag to normal builds, IMO.

  Or, for maintainer mode, always relax the comments restriction only so we
  always add -Wno-error=comment. You can almost call this c99-lite which
  solves one c99'ism in newer system headers without allowing all possible
  c99'isms in system headers, and without overriding the -std flag defaults
  at all.

  Or, introduce no -std flag, similar to above, and only in the clang 5 case
  add -Wno-error=comment in apr maintainer mode so that even if
  -std=c89 is toggled elsewhere, that particular error is overriden.

This is the current APR maintainer-mode logic;

AC_ARG_ENABLE(maintainer-mode,[  --enable-maintainer-mode  Turn on
debugging and compile time warnings],
  [APR_ADDTO(CFLAGS,-g)
   if test "$GCC" = "yes"; then
 APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations])
  case `($CC --version) 2>/dev/null` in
*clang-900* | *"clang version 5.0.0"*)
  APR_ADDTO(CFLAGS,[-Wno-error=strict-prototypes])
  ;;
  esac
   elif test "$AIX_XLC" = "yes"; then
 APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
   fi
])dnl

Note that there is no future-proofing here, clang 5.0.1 or 5.1.0 wouldn't
escape the strict-prototypes omission (and wondering, why it was needed in
the first place, if not for system headers again.)

Contrast to httpd 2.4's set of flags; -std=c89 -Werror -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
-Wunused

So, what would folks propose we change to APR 1.7.0 maintainer mode, or
does anyone have a positive thought on the above three options?

Re: http://svn.apache.org/r1850745

[William A Rowe Jr]

Just as a reminder of what r1850745 actually did, from an old discussion;

On Wed, Jan 16, 2019 at 5:09 PM William A Rowe Jr 
wrote:

> On Wed, Jan 16, 2019 at 3:54 PM Jim Jagielski  wrote:
>
>> I'm sorry but I'm confused. The patch is as specific as you can get. It
>> just adds the minimal option and JUST for filters and JUST if libxml2 is
>> part of the build.
>>
>
> Understood, but you might have overlooked the fact that changing CPPFLAGS
> (or CFLAGS - even worse) changes it for the entire build.
>
> My normal config, without your patch;
> ./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
> ./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
> ./build/config_vars.mk:PICFLAGS =
> ./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
> ./build/config_vars.mk:CPPFLAGS =
> ./build/config_vars.mk:CFLAGS =
> ./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
> ./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
> -Wunused
> ./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
> ./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -Wall -Wmissing-prototypes
> -Wstrict-prototypes -Wmissing-declarations -pthread
> ./build/config_vars.mk:INTERNAL_CPPFLAGS =
>
> With your patch in 2.5.x;
> ./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
> ./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
> ./build/config_vars.mk:PICFLAGS =
> ./build/config_vars.mk:UNITTEST_CFLAGS = -pthread
> ./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
> ./build/config_vars.mk:CPPFLAGS =
> ./build/config_vars.mk:CFLAGS =
> ./build/config_vars.mk:CFLAGS_FOR_BUILD =
> ./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
> ./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
> -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
> -Wunused -Wno-error=comment
> ./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
> ./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -pthread
> ./build/config_vars.mk:INTERNAL_CPPFLAGS =
>
> As you can see, you didn't modify only modules/filters/ ... Maybe you
> meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?
>
>
>> Anything else seems more disruptive than that. So why are the more
>> disruptive changes preferred? I'm just trying to understand the logic there.
>>
>
> My thought is that your observation was spot-on that libxml2, but soon
> more and more system headers will introduce C99 headers, and there is
> no reason to apply just the bandaid, certainly not to the whole server
> based on accumulated individual modules/foo/config.m4 bandaids.
> That's my objection to the commit in trunk.
>
> If we agree this is a problem to solve, let's not presume libxml2 will
> be the end of it, and produce another tarball that gets broken with
> maintainer mode in the next OS release of your favorite *nix?
> I'm seeing it as inevitable that we should allow all manner of
> c99'isms from system headers when we build in our most strict mode,
> but when we don't build in maintainer-mode, to leave things at c89
> without -Wall etc. I see that as the most flexible compromise, without
> suggesting that we *add* c99'isms to httpd itself, just yet.
>

On Wed, Mar 13, 2019 at 7:43 AM Jim Jagielski  wrote:

> Is there anyone else building 2.4 on macOS under maintainer-mode
> who is also being affected by the above? The fact that I seem to
> be the anyone "complaining" :) seems weird...
>
> Thx!
>

Re: http://svn.apache.org/r1850745

[William A Rowe Jr]

On Wed, Mar 13, 2019 at 8:04 AM Jim Jagielski  wrote:

>
> Yeah, I also think it depends on the version of clang... previous versions
> did not flag
>
> /usr/local/include/unicode/uenum.h:1:1: error: // comments are not
> allowed in this language [-Werror,-Wcomment]
>
> as fatal errors.


Just looking on Fedora 29, their distribution and truly the vanilla libxml2
source package 2.9.9...

In include/libxml2 tree (dropping all the dups);
grep -r "#include" . | grep -v "
./SAX.h:#include 
./xmlwriter.h:#include 
./tree.h:#include 
./nanoftp.h:#include 
./encoding.h:#include 
./encoding.h:#include 

That's about as vanilla as things get for a C project; no '//' comments.
the problem is in the last item, as you observe above;
 /usr/local/include/unicode/uenum.h:1:1: error: // comments are not allowed
in this language [-Werror,-Wcomment]

Confirmed `grep -r "^[\t ]*//" .` on FC29 that modern /usr/include/unicode/
is full of '//' comments, entirely because...
// © 2016 and later: Unicode, Inc. and others.
// License & terms of use: http://www.unicode.org/copyright.html
/*
***
*
*   Copyright (C) 2002-2013, International Business Machines
...

unicode maintainers did a simple mass-license-update pass in 2016 through
these files using C99/C++ conventions without thinking much about it. The
relevant package on FC29 is libicu-devel-62.1-3.fc29.x86_64 : ("Development
files for International Components for Unicode").

gcc (GCC) 8.3.1 as shipping on FC29 does not flag these comments. Seems
like clang might have become too enthusiastic about enforcing only K
comments, lending the question of whether this is quirk falls entirely on
Apple.

Incomplete communications of OpenSSL 1.1.1 compatibility?

[William A Rowe Jr]

I was just updating PR 63212 and could not point the user at a top-level,
definitive statement that they were trying to accomplish something very
unwise and which they should have known better. Apparently there are few
sources of this information. From http://httpd.apache.org/ ...


Apache httpd 2.4.38 Released 2019-01-22


The Apache Software Foundation and the Apache HTTP Server Project are
pleased to announce  the
release of version 2.4.38 of the Apache HTTP Server ("httpd").

This latest release from the 2.4.x stable branch represents the best
available version of Apache HTTP Server.


This seems to be somewhat unhelpful from a top-level knowledge point of
view, it doesn't indicate that they should choose 2.4.38 over 2.4.37 for
any particular reason, or that they would *need* to choose 2.4.38 if they
wished to have a server running against OpenSSL 1.1.1 and later.

Is there a way to improve communication of "do not use" guidance, outside
of information at http://httpd.apache.org/security/vulnerabilities_24.html
nested two-clicks deep?

I do not see such guidance at http://www.apache.org/dist/httpd/ either, the
Announcement does not suggest anything. Also finding the offending 2.4.37
release still available for download (surely just an oversight.)

Note PR 63212 may be entirely specific to AIX, and may be a side effect of
build schema changes of OpenSSL 1.1.1 itself. Sorry I no longer have the
hardware to explore such issues.

Re: http workshop

[William A Rowe Jr]

On Thu, Feb 14, 2019 at 2:36 PM Mark Thomas  wrote:

> On 14/02/2019 19:52, William A Rowe Jr wrote:
> > On Mon, Jan 28, 2019 at 9:22 AM Stefan Eissing <
> stefan.eiss...@greenbytes.de>
> > wrote:
>
> 
>
> >> The HTTP WS organisers expressed the wish to have someone from "Apache"
> >> present. Anyone interested? Could also be someone from another HTTP
> related
> >> Apache project, of course.
>
> It appears that the deadline to submit a statement of interest in
> attending was a month ago.
>
> Has it been extended?
>

I understand they are at capacity, so anyone applying to attend would be
waitlisted.

Re: http workshop

[William A Rowe Jr]

On Mon, Jan 28, 2019 at 9:22 AM Stefan Eissing 
wrote:

> The HTTP Workshop is returning 2019 on April 2-4 in Amsterdam (
> https://github.com/httpworkshop/workshop2019). While I attended the last
> three shops(?), I think it would be a good opportunity for someone else
> from the team to go there and meet some smart and friendly people from the
> HTTP world.
>

I found Daniel's blogs on the last (2017) meetup very helpful for context;
https://daniel.haxx.se/blog/2017/06/12/http-workshop-london-edition-first-day/
https://daniel.haxx.se/blog/2017/06/13/http-workshop-s03e02/

It seems there is little retrospective of HTTP/1.1, while
challenges/footnotes to h2 and tls1.3 will be discussed, and waka (would be
good to hear an update from Roy on this) and quik seem to still be the
primary topics of the day. So someone interested in writing the HTTP/3
implementation for httpd would be the obvious choice of delegate. (Hoping
Roy already plans to attend.)

One issue that has reared its ugly head again and again for us is URL
conformance and ambiguity, and especially early decoding of % escapes (and
non-normative %U escapes that may try to pass through proxies.) Since there
was discussion of completely refactoring URL encoding/decoding patterns in
httpd 3.0, someone interested in proceeding on that work would make a
helpful workshop liason.

Another issue of interest is bidirectional and push content, which the
httpd core largely ignores but could better support. Although that's
probably off in the weeds for browser and middle-tier folks. The usefulness
of 100-Continue through proxies and mis-interpretations of the spec on this
might be interesting conversation.

The HTTP WS organisers expressed the wish to have someone from "Apache"
> present. Anyone interested? Could also be someone from another HTTP related
> Apache project, of course.
>

It seems TrafficServer is already in the loop, as Leif attended last time.
Tomcat is an obvious gap, cc'ed.

Also seems that Tatsuhiro is in the loop, having attended in 2016 and being
key to httpd's support of h2 protocol.

It might be that the HTTP/3 .. quik implementation, if httpd gains one,
ultimately looks like mod_h2, a layer over another's implementation.

Re: Tidy up SVN commit lists

[William A Rowe Jr]

On Wed, Feb 13, 2019 at 4:12 PM sebb  wrote:

> HTTPD has several commit lists configured in asf-mailer.conf
>
> The default:
> to_addr = c...@httpd.apache.org
>
> E) # can be dropped?
> for_paths = httpd/httpd/win32-msi
> to_addr = win32-msi-...@httpd.apache.org
>

The last commit for E) was in 2013. I suspect the separate list could
> be dropped.
>

Yes, this can be routed to cvs@httpd.a.o. If it gains any activity
(unlikely)
it can notify the general address until it becomes annoying enough to
parcel off to it's own space again. The only irritating commits would occur
when a large number of target files for installation are changed at once
(e.g. the delta between 2.2 and 2.4) which are very rare things.


> This would allow B) to be dropped as well
>

+1

Re: Close mbox-cvs@ mailing list?

[William A Rowe Jr]

On Sun, Jan 20, 2019 at 7:02 PM sebb  wrote:

> The mbox-cvs@httpd used to be used for mbox commit messages.
>
> However these now seem to be sent to cvs@
>
> AFAICT there is no need to keep the list.
>
> Agreed?
>

Right call. The same is true of apreq-cvs@httpd, the commits should
be going to cvs@httpd, and the list closed.

Similarly with apreq-dev@httpd, this list can be closed, since that code
was adopted by dev@httpd 8 years ago. The list was alerted to this
change some months ago, I just hadn't gotten back to filing an infra
ticket to make it so.

Re: [PATCH] mod_proxy: fix build without APR threads

[William A Rowe Jr]

On Tue, Jan 22, 2019 at 10:30 AM Stefan Sperling  wrote:

> On Tue, Jan 08, 2019 at 03:46:48PM +0100, Stefan Sperling wrote:
> > mod_proxy fails to compile when APR doesn't have thread support.
> > I don't know if this is supposed to be a supported configuration,
> > but this problem did not exist with HTTPD 2.2; it showed up in 2.4.
>

How early in 2.4? I believe no-threads/prefork/mod_proxy had been
a supported combo during 2.4.1+ lifetime. It should be corrected.
mod_proxy_balancer doesn't make any sense, of course, so if it
has similar issues, those aren't a worry.

> The patch below adds checks for APR_HAS_THREADS and passes test
> > builds with both threaded and non-threaded APR from APR's trunk.
> > Is this the right approach?
> >
> > I also found that the http2 module won't build without thread support.
>

This is rather known. Early in the mod_http2 adoption, it was decided
that it would not support mod_prefork. Since it only supports threaded
MPM's, that's fine, it can be disabled for no-threads.


> > I can simply omit http2 from my SVN dev builds, for now. But mod_proxy
> > is required by mod_dav_svn for SVN's write-through proxy feature.
>


> Any feedback on this? Should I just commit it if I don't hear anything?
>

You can commit what you believe is the right fix to trunk, and propose
this for backport in STATUS for 2.4 branch for others to consider, test
and collect the 3 +1's needed for backporting.

Sayonara httpd pmc

[William A Rowe Jr]

In private business, Greg Stein explicitly asked me

"I no longer wish you to be part of this PMC"

and as such, I've tendered, and my resignation was promptly
accepted promptly by the committee chair.

I look forward to working with you to solve occasional httpd bugs,
but no longer speak to or for the project, nor to its structure.

Cheers,

Bill

Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h

[William A Rowe Jr]

On Thu, Jan 17, 2019 at 12:07 PM William A Rowe Jr 
wrote:

> On Thu, Jan 17, 2019 at 12:03 PM Daniel Ruggeri 
> wrote:
>
>>
>> We had a commit after the tag,
>
>
> There are no tags. They are figments of your imagination :) When we
> publish a tarball (even just under /dev/dist/), then we have a tag.
>
> Please svn rm the errant 2.4.39 tag.
>

(erm... svn rm the 2.4.38 tag I mean, please avoid modifying the files
beneath /tags/.)


> so I've updated only the STATUS/CHANGES
>> files to correct the errant lines. I also svn rm'ed the extra tree under
>> the 2.4.28 tag.
>>
>
> What about fixing ap_release.h please?
>

Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h

[William A Rowe Jr]

On Thu, Jan 17, 2019 at 12:03 PM Daniel Ruggeri 
wrote:

>
> We had a commit after the tag,


There are no tags. They are figments of your imagination :) When we
publish a tarball (even just under /dev/dist/), then we have a tag.

Please svn rm the errant 2.4.39 tag.

so I've updated only the STATUS/CHANGES
> files to correct the errant lines. I also svn rm'ed the extra tree under
> the 2.4.28 tag.
>

What about fixing ap_release.h please?

Re: [VOTE] Release httpd-2.4.28

[William A Rowe Jr]

An aside r.e. subversion;

Just please don't do what gstein has warned us against. I've performed
the ill-advised jump-over abandoned work in the past;
   svn rm ^/httpd/mod_foo/trunk
   svn cp ^/httpd/mod_foo/trunk@123456 ^/httpd/mod_foo/trunk
attempting to drop activity between 123457 and present. Greg advised
us this turns out to do some ugly rebasing leaving a very ugly mess of
records in the underlying database. Anyone from subversion team could
give a better explanation why this is badness. This might look like
a reversion, but don't do this.

On Thu, Jan 17, 2019 at 12:00 PM Daniel Gruno  wrote:

>
> It's subversion, not git - we can always revert ;p
>

Re: svn commit: r1851557 - /httpd/httpd/branches/2.4.x/include/ap_release.h

[William A Rowe Jr]

One problem with scripts, they do just what they are told.

You just tagged 2.4.39 as 2.4.38.

Please revert to 2.4.38 and tag - until the tarballs are published to vote
on,
it's all development in svn history.

On Thu, Jan 17, 2019 at 11:48 AM  wrote:

> Author: druggeri
> Date: Thu Jan 17 17:48:40 2019
> New Revision: 1851557
>
> URL: http://svn.apache.org/viewvc?rev=1851557=rev
> Log:
> Get ready to tag httpd 2.4.38
>
> Modified:
> httpd/httpd/branches/2.4.x/include/ap_release.h
>
> Modified: httpd/httpd/branches/2.4.x/include/ap_release.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_release.h?rev=1851557=1851556=1851557=diff
>
> ==
> --- httpd/httpd/branches/2.4.x/include/ap_release.h (original)
> +++ httpd/httpd/branches/2.4.x/include/ap_release.h Thu Jan 17 17:48:40
> 2019
> @@ -44,7 +44,7 @@
>  #define AP_SERVER_MAJORVERSION_NUMBER 2
>  #define AP_SERVER_MINORVERSION_NUMBER 4
>  #define AP_SERVER_PATCHLEVEL_NUMBER   39
> -#define AP_SERVER_DEVBUILD_BOOLEAN1
> +#define AP_SERVER_DEVBUILD_BOOLEAN0
>
>  /* Synchronize the above with docs/manual/style/version.ent */
>
>
>
>

Re: [VOTE] Release httpd-2.4.28

[William A Rowe Jr]

On Thu, Jan 17, 2019 at 11:44 AM Jim Jagielski  wrote:

> Note that simply changing the commit msg logs does not solve the problem.
> There is,
> in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real"
> 2.4.28 tag... :(


Not destroyed, as ylavic observed.

Nothing gets destroyed in revision control without a ton of extra effort
(at least not in subversion... git is another story.)

Re: svn propchange: r1851549 - svn:log

[William A Rowe Jr]

Ahhh, true. Adjusted message appropriately.

On Thu, Jan 17, 2019 at 11:44 AM Yann Ylavic  wrote:

> On Thu, Jan 17, 2019 at 6:36 PM  wrote:
> >
> > Author: wrowe
> > Revision: 1851549
> > Modified property: svn:log
> >
> > Modified: svn:log at Thu Jan 17 17:36:04 2019
> >
> --
> > --- svn:log (original)
> > +++ svn:log Thu Jan 17 17:36:04 2019
> > @@ -1 +1,3 @@
> > -Tag HEAD of 2.4.x as 2.4.28
> > +Tag HEAD of 2.4.x as 2.4.38
> > +
> > +[Corrected commit message]
>
> No it's not AFAICT, the tag existed already so it all ended up as a
> subdirectory of tags/2.4.28 (see below).
>
> Added:
> httpd/httpd/tags/2.4.28/2.4.x/   (props changed)
>   - copied from r1851548, httpd/httpd/branches/2.4.x/
>
> Propchange: httpd/httpd/tags/2.4.28/2.4.x/
>

Re: svn commit: r1850835 - /httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c

[William A Rowe Jr]

On Thu, Jan 17, 2019 at 4:03 AM Joe Orton  wrote:

> On Wed, Jan 16, 2019 at 12:02:01PM -0600, William A Rowe Jr wrote:
> > Doesn't this simply gloss over an underlying defect?
> >
> > [...]
> > if (apr_dbm_fetch(f, key, ) == APR_SUCCESS && val.dptr) {
> > *value = apr_pstrmemdup(pool, val.dptr, val.dsize);
> > }
> >
> > apr_dbm_close(f);
> >
> > return rv;
> > }
> >
> > Shouldn't we capture and return the failure code from apr_dbm_fetch here?
>
> The error code from the failed lookup is not an interesting result, I
> assume because it can only fail one way.  That the lookup failed is
> reflected by returning with success *value set to NULL.
>
> I had this change in my wc from looking at clang/coverity static
> analysis results so I assume it was flagged up somewhere but can't
> remember exactly.  It seems like a harmless change.
>

Thanks for the reminder, yes... most providers will return only found
or not found; not found is not an error. However some providers may
fault, e.g. DB corrupt or storage interrupted or some other very rare
edge case. APR provided to return this info, whether the underlying
provider does is another question.

I'm concerned if clang/coverity flagged the existing code, since that
suggests some edge case that may not optimize correctly.

I withdraw my objection if we layer on the following comment to
avoid future confusion/research;

/* NOT FOUND is not an error case; this is indicated by NULL result.
 * Treat all NULL lookup/error results as success for the simple case
 * of auth credential lookup, these are DECLINED in both cases.
 */

Does that sound like a resolution Joe?

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[William A Rowe Jr]

On Wed, Jan 16, 2019 at 3:54 PM Jim Jagielski  wrote:

> I'm sorry but I'm confused. The patch is as specific as you can get. It
> just adds the minimal option and JUST for filters and JUST if libxml2 is
> part of the build.
>

Understood, but you might have overlooked the fact that changing CPPFLAGS
(or CFLAGS - even worse) changes it for the entire build.

My normal config, without your patch;
./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
./build/config_vars.mk:PICFLAGS =
./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
./build/config_vars.mk:CPPFLAGS =
./build/config_vars.mk:CFLAGS =
./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
-Wunused
./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -pthread
./build/config_vars.mk:INTERNAL_CPPFLAGS =

With your patch in 2.5.x;
./build/config_vars.mk:SHLTCFLAGS = -prefer-pic
./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static
./build/config_vars.mk:PICFLAGS =
./build/config_vars.mk:UNITTEST_CFLAGS = -pthread
./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include
./build/config_vars.mk:CPPFLAGS =
./build/config_vars.mk:CFLAGS =
./build/config_vars.mk:CFLAGS_FOR_BUILD =
./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG
./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security
-Wunused -Wno-error=comment
./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE
./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -pthread
./build/config_vars.mk:INTERNAL_CPPFLAGS =

As you can see, you didn't modify only modules/filters/ ... Maybe you
meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does?


> Anything else seems more disruptive than that. So why are the more
> disruptive changes preferred? I'm just trying to understand the logic there.
>

My thought is that your observation was spot-on that libxml2, but soon
more and more system headers will introduce C99 headers, and there is
no reason to apply just the bandaid, certainly not to the whole server
based on accumulated individual modules/foo/config.m4 bandaids.
That's my objection to the commit in trunk.

If we agree this is a problem to solve, let's not presume libxml2 will
be the end of it, and produce another tarball that gets broken with
maintainer mode in the next OS release of your favorite *nix?
I'm seeing it as inevitable that we should allow all manner of
c99'isms from system headers when we build in our most strict mode,
but when we don't build in maintainer-mode, to leave things at c89
without -Wall etc. I see that as the most flexible compromise, without
suggesting that we *add* c99'isms to httpd itself, just yet.

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[William A Rowe Jr]

In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
in maintainer mode, or simply switch to -std=c99 presuming that more
and more of the system headers follow c99 syntax over time.
And revert the tweak of modules/filters/config.m4.

On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:

>
> C2 General
>
> > -Ursprüngliche Nachricht-
> > Von: Stefan Eissing 
> > Gesendet: Mittwoch, 16. Januar 2019 10:00
> > An: dev@httpd.apache.org
> > Betreff: Re: svn commit: r1850745 -
> > /httpd/httpd/trunk/modules/filters/config.m4
> >
> >
> >
> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr  > clan.net>:
> > >
> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  wrote:
> > >
> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski 
> > wrote:
> > > >>
> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr 
> > wrote:
> > > >>
> > > >> Hi Jim,
> > > >>
> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
> > building on the Fedora 29, largely frozen end-of-july. Reverting the
> > patch below and toggling -std=c89 to -std=c99 in configure.in building
> > all but two modules from trunk is building clean, and results in this
> > command for error checking;
> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
> > pthread -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -
> > Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -
> > D_GNU_SOURCE -DAP_DEBUG
> > > >>
> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
> > not suggesting we change the general builds from c89 in the 2.4 branch,
> > but that is something we might want to consider for trunk, 20 years out.
> > > >>
> > > >>
> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
> > considering that we are in 2019 already :)
> > > >>
> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
> > anyway.
> > > >
> > > > As a binary distributor, even though a C99 compiler may be available
> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
> > > > 2.4.
> > >
> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
> > :)
> > >
> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
> > c89) possibly more difficult. This is either a good thing or a bad
> > thing. So far, however, iirc we have not had any issues sticking with
> > c89 and I don't think the above would warrant such a change. IMO of
> > course.
> > >
> > > I might not have been clear, above. I'm not suggesting changing things
> > for the
> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
> > think we should
> > > have this discussion of when we will begin accepting c99 source
> > patches, but
> > > that isn't the immediate problem you've tripped over.
> > >
> > > I see several options;
> > >
> > >   Only for maintainer mode, where we are strictly handling all errors,
> > always
> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
> > may arise.)
> > >   All the system headers using c99 (or earlier) semantics should
> > behave well.
> > >
> > >   Or, for maintainer mode, always relax the comments restriction only
> > so we
> > >   have -std=c89 -Werror -Wall -Wno-error=comment (but not modified in
> > the
> > >   modules/filters/config.m4 where it isn't apparent who toggled this.)
> > You can
> > >   almost call this c99-lite which solves one c99'ism in newer system
> > headers
> > >   without allowing all the c99'isms in system headers.
> > >
> > >   Or, staying closest to the proposed patch, add -Wno-error=comment
> > only
> > >   to mod_proxy_html's CPPFLAGS, and stop messing with the rest of the
> > >   compilation for a single module.
> > >
> > > In every case, I'm expecting we still adhere to c89, especially in
> > httpd-2.4
> > > branch. A typical compilation (non-maintainer-mode) should catch most
> > > of those irregularities.
> >
> > My pov:
> > - as long as 2.4.x is our only release branch, I'd like trunk maintainer
> > mode to stay compatible
> > - I would like to switch to c99 as soon as 2.6.0 is out
> > - The CPPFLAGS switch for the module only seems to be the least
> > intrusive
>
> Sounds sensible.
>
> Regards
>
> Rüdiger
>

Re: svn commit: r1850835 - /httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c

[William A Rowe Jr]

Doesn't this simply gloss over an underlying defect?

[...]
if (apr_dbm_fetch(f, key, ) == APR_SUCCESS && val.dptr) {
*value = apr_pstrmemdup(pool, val.dptr, val.dsize);
}

apr_dbm_close(f);

return rv;
}

Shouldn't we capture and return the failure code from apr_dbm_fetch here?

On Wed, Jan 9, 2019 at 3:34 AM  wrote:

> Author: jorton
> Date: Wed Jan  9 09:34:34 2019
> New Revision: 1850835
>
> URL: http://svn.apache.org/viewvc?rev=1850835=rev
> Log:
> * modules/aaa/mod_authn_dbm.c (fetch_dbm_value): No functional change:
>   return APR_SUCCESS rather than rv, which is guaranteed to be
>   APR_SUCCESS in current code.
>
> Modified:
> httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c
>
> Modified: httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c?rev=1850835=1850834=1850835=diff
>
> ==
> --- httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c (original)
> +++ httpd/httpd/trunk/modules/aaa/mod_authn_dbm.c Wed Jan  9 09:34:34 2019
> @@ -101,7 +101,7 @@ static apr_status_t fetch_dbm_value(cons
>
>  apr_dbm_close(f);
>
> -return rv;
> +return APR_SUCCESS;
>  }
>
>  static authn_status check_dbm_pw(request_rec *r, const char *user,
>
>
>

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[William A Rowe Jr]

On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  wrote:

>
> > On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
> >
> > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski  wrote:
> >>
> >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr 
> wrote:
> >>
> >> Hi Jim,
> >>
> >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
> building on the Fedora 29, largely frozen end-of-july. Reverting the patch
> below and toggling -std=c89 to -std=c99 in configure.in building all but
> two modules from trunk is building clean, and results in this command for
> error checking;
> >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -pthread
> -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
> -Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -D_GNU_SOURCE
> -DAP_DEBUG
> >>
> >> Is it reasonable to enforce c99 limitations at this late date? I'm not
> suggesting we change the general builds from c89 in the 2.4 branch, but
> that is something we might want to consider for trunk, 20 years out.
> >>
> >>
> >> Personally, I'd be fine allowing c99 in both 2.4 and trunk, considering
> that we are in 2019 already :)
> >>
> >> Any platform that lacks a c99 compatible CC likely doesn't build anyway.
> >
> > As a binary distributor, even though a C99 compiler may be available
> > on platform X, it might not be in use.  Wouldn't love seeing it in
> > 2.4.
>
> I'm not proposing a change for 2.4... but I wouldn't oppose it either :)
>
> Allowing c99 for trunk would make backporting to 2.4 (which would stay
> c89) possibly more difficult. This is either a good thing or a bad thing.
> So far, however, iirc we have not had any issues sticking with c89 and I
> don't think the above would warrant such a change. IMO of course.


I might not have been clear, above. I'm not suggesting changing things for
the
customary build, leave that (at least on httpd 2.4) as -std=c89. I think we
should
have this discussion of when we will begin accepting c99 source patches, but
that isn't the immediate problem you've tripped over.

I see several options;

  Only for maintainer mode, where we are strictly handling all errors,
always
  accept all -std=c99 behaviors (fix any legacy pre-c99 issues that may
arise.)
  All the system headers using c99 (or earlier) semantics should behave
well.

  Or, for maintainer mode, always relax the comments restriction only so we
  have -std=c89 -Werror -Wall -Wno-error=comment (but not modified in the
  modules/filters/config.m4 where it isn't apparent who toggled this.) You
can
  almost call this c99-lite which solves one c99'ism in newer system headers
  without allowing all the c99'isms in system headers.

  Or, staying closest to the proposed patch, add -Wno-error=comment only
  to mod_proxy_html's CPPFLAGS, and stop messing with the rest of the
  compilation for a single module.

In every case, I'm expecting we still adhere to c89, especially in httpd-2.4
branch. A typical compilation (non-maintainer-mode) should catch most
of those irregularities.

Re: [NOTICE] Intent to T 2.4.28

[William A Rowe Jr]

On Tue, Jan 15, 2019 at 8:16 AM Jim Jagielski  wrote:

> Could I please get one more vote on adding in mod_socache_redis from
> trunk...
>

This suggests one more adopter/reviewer. Has anyone in the community
been using this module and can vouch for it? Anyone is welcome to share
your votes here at dev@ on anything in the STATUS review file, whether
you are a committer or not.

https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/STATUS

If there are no users interested, adopting the responsibility of
maintaining
this seems unwise.

Re: Is it interesting to add some filepath checks to apachectl -t ?

[William A Rowe Jr]

There should not be a 'warn' level emit for a non-existent directory.
Unlike the
DocumentRoot or Alias, which are searched,  blocks describe
protection. It's entirely reasonable to protect paths which aren't
physically on
the system at the current moment or in the current deployment. Something
at the 'debug' level would be entirely reasonable, perhaps even at 'info'
level.


On Sun, Jan 13, 2019 at 3:39 PM Stéphane Blondon 
wrote:

> Hello,
>
> sorry for the huge delay :/
>
> >>> On 03/07/2018 22:57, Stéphane Blondon wrote:
>  Hello,
> 
>  `apachectl -t` checks the configuration files. The documentation
>  explains it's not complete.
>  It seems paths (for DocumentRoot for example) or the write access for
>  log directory are not checked. (tested with apache v.2.4.25.)
>
> On 02/09/2018 13:56, Daniel Ferradal wrote:
> > but httpd is invoked from it and already checks if document root exists
> and
> > if does not it does not start, and log directory is always writable
>
>
> You're right: I tested with a more recent version (2.4.37) and
> 'DocumentRoot' path and logs directories ('ErrorLog' and 'CustomLog')
> are checked.
>
> I wonder if `apachectl -t` should provide a warning if the path for
> 'Directory' directive does not exist.
>
> For example, 
> if /var/www/demo does not exist, `apachectl -t` does not complain. I
> though it would display a warning like AH00112 for DocumentRoot:
> Warning: DocumentRoot [/var/www/demo] does not exist
>
>
> Regards,
> Stéphane
>
>

Re: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[William A Rowe Jr]

Hi Jim,

Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm building
on the Fedora 29, largely frozen end-of-july. Reverting the patch below and
toggling -std=c89 to -std=c99 in configure.in building all but two modules
from trunk is building clean, and results in this command for error
checking;
/usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -pthread
-std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith
-Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -D_GNU_SOURCE
-DAP_DEBUG

Is it reasonable to enforce c99 limitations at this late date? I'm not
suggesting we change the general builds from c89 in the 2.4 branch, but
that is something we might want to consider for trunk, 20 years out.

If we did use the patch below, I suspect we would rather tweak the CPPFLAGS
of only the single module, and not modify the CPPFLAGS of all sources, if
we can avoid that unexpected side-effect.

On Tue, Jan 8, 2019 at 7:12 AM  wrote:

> Author: jim
> Date: Tue Jan  8 13:12:34 2019
> New Revision: 1850745
>
> URL: http://svn.apache.org/viewvc?rev=1850745=rev
> Log:
> This just got me. I upgraded macOS to Mojave (w/ latest Xcode) and I
> always build w/ maintainer-mode. The problem is that libxml2 will include
> various unicode/*.h files that have C++ type comments, which causes
> building to fail (due to Werror). Work around this.
>
> Modified:
> httpd/httpd/trunk/modules/filters/config.m4
>
> Modified: httpd/httpd/trunk/modules/filters/config.m4
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/config.m4?rev=1850745=1850744=1850745=diff
>
> ==
> --- httpd/httpd/trunk/modules/filters/config.m4 (original)
> +++ httpd/httpd/trunk/modules/filters/config.m4 Tue Jan  8 13:12:34 2019
> @@ -114,6 +114,10 @@ AC_DEFUN([FIND_LIBXML2], [
>  if test -n "${xml2_path}" ; then
>ac_cv_libxml2=yes
>XML2_INCLUDES="${xml2_path}"
> +  dnl libxml2 includes unicode/*.h files which uses C++ comments
> +  if test "$GCC" = "yes"; then
> +APACHE_ADD_GCC_CFLAG([-Wno-error=comment])
> +  fi
>  else
>ac_cv_libxml2=no
>  fi
>
>
>

Re: svn commit: r1849177 - /httpd/httpd/trunk/CHANGES

[William A Rowe Jr]

On Wed, Dec 19, 2018 at 12:19 AM Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

>
> I thought that now that 2.5.0 has been tagged, the history of 2.5.0+
> should not be axed when backported (i.e. this change would be in 2.5.1,
> but is not in 2.5.0, which is tagged, so "does exist")
>

You are correct in spirit, but in practice, 2.5.0 was not released, and
therefore does not "exist". If the release vote for 2.5.1-alpha (or -beta)
does pass, then the 2.5 clock will truly start.

Re: [PATCH] mod_deflate: hardcoded "%ld" -> APR_OFF_T_FMT

[William A Rowe Jr]

On Sun, Dec 16, 2018 at 7:27 AM Yann Ylavic  wrote:

>
> Since it's logging only, it may be easier to cast to (long) each
> total_in/out though.
>

Downcast? Why not upcast to apr_off_t and use the _FMT macro as first
suggested?

Re: 2.4.38

[William A Rowe Jr]

On Sun, Nov 11, 2018 at 3:54 PM Barry Pollard 
wrote:

> You only have to look at the past few attempts (scrapped versions) to
> release apache to see the dangers in rush rush rush attitude.
>
> I’m assuming it’s a given that httpd should only release when ready to. I
> don’t think any of the release-often advocates are suggesting taking less
> care with releases or releasing untested code. My question is would any
> more testing go on if we did release less frequently? On one side I get the
> argument that more time between releases theoretically allows for more
> testing time, but I question whether anyone would use that time for that?
> My experience of software development (outside of httpd) suggests not.
>

Something that is specific to httpd as opposed to other projects...

Many projects today follow the -RC1 -RC2 -RC3 ... final release pattern.

HTTPD project as a collection of patches always agreed that once a tarball
of source code files was assembled, that the number assigned to it would
never change. There would be no post-release changes to that tarball to
designate it as a release.

Therefore in the 2.4.x timeline, roughly 1/3 of the version numbers were
"duds". Nobody observed these outside of the dev@ list and the specific
http://httpd.apache.org/dev/ space (and associated development tags in
subversion), because these aren't announced until they are accepted.

This simply does not differ from other major project's success/failure rate
of their -RC1, -RC2 attempts at collecting an "acceptable" release. Only
the naming convention differs.

Re: 2.4.38

[William A Rowe Jr]

On Fri, Nov 9, 2018 at 2:04 PM Graham Leggett  wrote:

> On 09 Nov 2018, at 17:51, Stefan Eissing 
> wrote:
>
> > So, the chance is high that releases we do will work for most of you.
> > AND the chance is high that releases might break something for some of
> you (hopefully a few).
>
> The chance is very low that releases might break something, and this is
> done by design.
>
> The place where we might break something is trunk. Before you get anywhere
> near a release, you have to carve out your change, and propose it for
> backport to a release branch. This is the first check. Two other people
> will then check your backport, and if problems are found you’ll be asked to
> fix it. That’s the second and third check. Then a release is proposed. A
> tarball is cut, and a whole lot of new people do checks on the tarball. In
> the case of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth,
> ninth, tenth and eleventh check for the 8 people who tested it.
>
> This strategy has worked very well for us since the 1990s, and we must not
> understate its importance.


Good summary, but it's inevitable, Stefan was pointing out that something
is likely to break
in a feature/enhancement release for *someone*. Not for the vast majority
of users who
have somewhat stock configurations, but for those with their own custom
modules or
filters or even build schemas that get touched when we add dependencies and
change
the influence (not necessarily the definition) of the directives.

The goal is to make that number of cases as small as possible, as you've
both pointed
out.

Thanks for the reminder/pointer to the rpm instructions.

Re: Load balancing and load determination

[William A Rowe Jr]

On Thu, Nov 8, 2018 at 1:48 PM Jim Jagielski  wrote:

> I have a semi-working implementation that I'll be committing to trunk in a
> bit...


 I'm confused. Semi-working would seem to be orthoganal to keeping trunk in
a releasable state, but it depends on what you mean. But before you commit
a significant change, please first consider posting the patch, or simpler,
please
consider a sandbox fork for iterative development?  From the project bylaws;

When to Commit a Change

Ideas must be review-then-commit; patches can be commit-then-review. With a
commit-then-review process, we trust that the developer doing the commit
has a high degree of confidence in the change. Doubtful changes, new
features, and large-scale overhauls need to be discussed before being
committed to a repository. Any change that affects the semantics of
arguments to configurable directives, significantly adds to the runtime
size of the program, or changes the semantics of an existing API function
must receive consensus approval on the mailing list before being committed.

Re: [resolution] Stale BZ Bug Tracker reports

[William A Rowe Jr]

I clicked send on this note, before I saw the deluge.

What we would not want is to hide closure notices to the cc recipients on
the issue. We would not want to remove bugs@ from the issue itself. And
anyone reconfirming a ticket is not stale is going to the bugs@
notification list.

My only thought on avoiding this in the future is to suspend the bugs@ list
entirely for a several minute period while the mass update notifications
are sent. Then restore the normal list behavior.

If you simply want to hide this mass update, I would unthread your mail
reader, and mass select and delete all email notices during that small 5
minute window.

Another option, I kept with threading, and mass deleted only those updates
with no other notices in a multi-year period. I'm now going back over some
70 closures which had an active discussion at some point in the not so
distant past.

Sorry for this somewhat painful side effect of this cleanup operation.
Since we've decided most other updates will employ some level of manual
scrutiny and intervention, there shouldn't be another burst of notices for
some years to come.

Re: Exposing SSL certificates on SNI mismatch

[William A Rowe Jr]

On Fri, Nov 9, 2018 at 2:03 AM Ruediger Pluem  wrote:

>
> On 11/08/2018 09:23 AM, Micha Lenk wrote:
> > Hi all,
> >
> > I have a customer asking about whether the SSL handshake can be made to
> fail in case the SNI from the "Client Hello"
> > message doesn't match at all any server name of the configured virtual
> hosts. E.g. consider a setup like this
> >
> > DNS records:
> > domain-a.tld resolves to 
> > domain-b.tld also resolves to 
> >
> > Listen :443 https
> > Listen :80  http
> >
> > :80>
> >   ServerName domain-a.tld
> >   ...
> > 
> >
> > :80>
> >   ServerName domain-b.tld
> > 
> >
> > :443>
> >   ServerName domain-b.tld
> >   SSLEngine On
> >   SSLCertificateFile <...a certificate file only valid for domain-b.tld>
> >   ...
> > 
> >
> > I.e. no virtual host with SSL enabled for domain-a.tld exists.
> >
> > In this setup the customer wants the server to not expose the SSL
> certificate of other, unrelated virtual hosts in case
> > a client/browser tries to access https:/domain-a.tld/ (which isn't
> configured in Apache).
> >
> > Is this currently possible? If yes, in 2.4.x or only trunk?
> >
> > I remember a discussion thread of this topic floating by, but I can't
> find it anymore. Does anybody else maybe have a
> > pointer to some public mail archive?
> >
> > Thanks a lot in advance for any comment,
>
> Currently there is no possibility to block this. You will only see AH02044
> if the loglevel is set to debug in this case.
> But I guess in the code block of the logmessage you could handle this by
> aborting the connection if a (new)
> configuration flag is set.


IIRC, this is a feature Stefan brought up recently... silently terminating
SSL
handshakes which don't follow expected SNI patterns, without a bunch of
info/warn associated log entries (perhaps without a log entry.)

However, the proposal above seems entirely silly. The information being
"guarded" from other vhost logs is publicly available to all through DNS.
But I think it is possible today. Prior to all other Vhost blocks, add...

:80>
   ServerName nomatch.example.tld
   ...


:443>
   ServerName nomatch.example.tld
   SSLCertificateFile <...self-signed certificate file with a non-matching
hostname>
   ...


All requests which don't match the later server names/SNI certs will
be handled through these garbage collection hosts. You can redirect
to a status 400 bad request response or anything you like, collecting
the error logs outside the scope of per-domain access/error logs.

The first matching vhost block is used when no ServerName/ServerAlias
matches are found.

[resolution] Stale BZ Bug Tracker reports

[William A Rowe Jr]

Mass update completed. Search criteria;

Version: 2.0-HEAD, 2.0.32, 2.0.35, 2.0.36, 2.0.39, 2.0.40, 2.0.42, 2.0.43,
2.0.44, 2.0.45, 2.0.46, 2.0.47, 2.0.48, 2.0.49, 2.0.50, 2.0.51, 2.0.52,
2.0.53, 2.0.54, 2.0.55, 2.0.58, 2.0.59, 2.0.61, 2.0.63, 2.0.64, 2.0.65,
2.1-HEAD, 2.2-HEAD, 2.2.0, 2.2.2, 2.2.3, 2.2.4, 2.2.6, 2.2.8, 2.2.9,
2.2.10, 2.2.11, 2.2.12, 2.2.13, 2.2.14, 2.2.15, 2.2.16, 2.2.17, 2.2.18,
2.2.19, 2.2.20, 2.2.21, 2.2.22, 2.2.23, 2.2.24, 2.2.25, 2.2.26, 2.2.27,
2.2.29, 2.2.31, 2.2.32, 2.2.33, 2.2.34, 2.3.11-beta, 2.3.12-beta,
2.3.14-beta, 2.3.15-beta Resolution: --- Status: NEW, NEEDINFO Product:
Apache httpd-2

715 bugs found.

Status updated; RESOLVED, LATER
Keyword added; MassUpdate
Comment added;
Please help us to refine our list of open and current defects; this is a
mass update of old and inactive Bugzilla reports which reflect user error,
already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued
all development and patch review of the 2.2.x series of releases. The final
release 2.2.34 was published in July 2017, and no further evaluation of bug
reports or security risks will be considered or published for 2.2.x
releases. All reports older than 2.4.x have been updated to status
RESOLVED/LATER; no further action is expected unless the report still
applies to a current version of httpd.

If your report represented a question or confusion about how to use an
httpd feature, an unexpected server behavior, problems building or
installing httpd, or working with an external component (a third party
module, browser etc.) we ask you to start by bringing your question to the
User Support and Discussion mailing list, see [
https://httpd.apache.org/lists.html#http-users] for details. Include a link
to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask
that you retest using a modern httpd release (2.4.33 or later) released in
the past year. If it can be reproduced, please reopen this bug and change
the Version field above to the httpd version you have reconfirmed with.

Your help in identifying the defects or enhancements to the current httpd
server software is greatly appreciated.

Re: Stale BZ Bug Tracker reports

[William A Rowe Jr]

On Fri, Nov 2, 2018, 06:24 Luca Toscano  Il giorno gio 1 nov 2018 alle ore 22:35 William A Rowe Jr
>  ha scritto:
> >
> > To keep this thread moving (additional feedback is welcomed and
> appreciated)...
>
> Thanks a lot for this effort William, I really think that having 1700+
> bugs opened does not look good for any reporter/user that doesn't know
> how we work, since it is easy to get the impression that bugs are
> simply opened to take dust for ages (thing that doesn't really
> happen).
>
>
> >
> > So I'd read this as the bug needs to be reproduced with a "later"
> version of httpd, and is subject to reconsideration "later" on further
> review, but may have already been resolved in a "later" release.
>
> The RESOLVED/FUTURE seems a bit confusing from my point of view, but I
> don't really have any good suggestion.. I would personally stick with
> something that clearly indicates that the bug was closed due to being
> too old.
>
> [Generic text comment proposed]
>
> +1 nice!
>
> > Edits noted, thanks!
>

It seems I should define that this bug may be reevaluated "LATER" and we
are asking for their help to close or reopen against a current flavor. I'll
work up a small tweak to the language we've agreed on.

We've given this enough cycles, I'll proceed to the initial step. Looking
for any tweaks which might let bugs mentioning "2.4." in the discussing to
be calldd out for manual reevaluation.

Re: Load balancing and load determination

[William A Rowe Jr]

On Mon, Nov 5, 2018 at 7:48 AM jean-frederic clere 
wrote:

> On 30/10/2018 13:53, Jim Jagielski wrote:
> > As some of you know, one of my passions and area of focus is
> > on the use of Apache httpd as a reverse proxy and, as such, load
> > balancing, failover, etc are of vital interest to me.
> >
> > One topic which I have mulling over, off and on, has been the
> > idea of some sort of universal load number, that could be used
> > and agreed upon by web servers. Right now, the reverse proxy
> > "guesses" the load on the backend servers which is OK, and
> > works well enough, but it would be great if it actually "knew"
> > the current loads on those servers. I already have code that
> > shares basic architectural info, such as number of CPUs, available
> > memory, loadavg, etc which can help, of course, but again, all
> > this info can be used to *infer* the current status of those backend
> > servers; it doesn't really provide what the current load actually
> > *is*.
> >
> > So I was thinking maybe some sort of small, simple and "fast"
> > benchmark which could be run by the backends as part of their
> > "status" update to the front-end reverse proxy server... something
> > that shows general capability at that point in time, like Hanoi or
> > something similar. Or maybe some hash function. Some simple code
> > that could be used to create that "universal" load number.
> >
> > Thoughts? Ideas? Comments? Suggestions? :)
>
> having the back-ends to provide the load they are able to handle
> lbfactor (via w_lf or somethere similar. That requires the back-ends to
> be able to send request to httpd balancer-manager handler.


Not really. I'd suggest a response header, travelling with each response
back to the balancer, which can be composed quickly enough to share
a play-by-play snapshot of the availability of that backend. This adds
next to no traffic and minimal cpu drain if composed cleanly. And it can
optionally be axed by the balancer in the response to the client.

The last thing we want are the routing headaches of contacting an
ever-changing list one-or-many potential balancers. And we can't
rely on a dying lbmember to "check in" that it isn't functional. Since
the balancer must already start requests to the backend, having that
backend supplement the responses with its health status is simple.

Re: __attribute__

[William A Rowe Jr]

On Thu, Nov 1, 2018 at 3:31 PM Jim Jagielski  wrote:

> Since __attribute__ is used in various places in trunk and 2.4, is it safe
> to assume that I can write something that requires __attribute__(packed)?


No ... but surely you meant to write __attribute__((packed))

The real question is... why? It is sorely suboptimal except on x86_64 where
the cpu handles the heavy lift ... the compiler must cope with it on
MIPS/SPARC/POWER etc, may break atomic updates (our atomics don't protect
against this), and doesn't address endianness. It all leads to lots of
other questions...

https://stackoverflow.com/questions/45116212/are-packed-structs-portable
https://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe

Adding this to any existing public struct definition is not backportable to
2.4.x.

A use case would be helpful provide a fair answer to your question.