Re: AW: mod_proxy_hcheck Compoent in bugzilla

2016-06-22 Thread Christophe JAILLET

Le 22/06/2016 à 22:49, Christophe JAILLET a écrit :

Le 22/06/2016 à 22:46, Christophe JAILLET a écrit :

Thx,

it seems that mod_proxy_http2 is missing as well.

Docs are also missing in 2.4 branch and should be added before T, 
IMHO.
Well, mod_proxy_hcheck.xml exists in 2.4.x, but html files seem to be 
missing.


CJ


Fixed.

CJ



AW: AW: mod_proxy_hcheck Compoent in bugzilla

2016-06-22 Thread Plüm , Rüdiger , Vodafone Group


> -Ursprüngliche Nachricht-
> Von: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
> Gesendet: Mittwoch, 22. Juni 2016 22:47
> An: dev@httpd.apache.org
> Betreff: Re: AW: mod_proxy_hcheck Compoent in bugzilla
> 
> Thx,
> 
> it seems that mod_proxy_http2 is missing as well.

Done as well.

Regards

Rüdiger

> 
> Docs are also missing in 2.4 branch and should be added before T,
> IMHO.
> 
> CJ
> 
> Le 22/06/2016 à 22:39, Plüm, Rüdiger, Vodafone Group a écrit :
> > Done.
> >
> > Regards
> >
> > Rüdiger
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
> >> Gesendet: Mittwoch, 22. Juni 2016 22:33
> >> An: dev@httpd.apache.org
> >> Betreff: mod_proxy_hcheck Compoent in bugzilla
> >>
> >> Hi,
> >>
> >> as it will be released soon, mod_proxy_hcheck should be added to
> >> bugzilla's Components list.
> >>
> >> I don't remind who to ask for it, so...
> >>
> >> CJ
> >>



Re: AW: mod_proxy_hcheck Compoent in bugzilla

2016-06-22 Thread Christophe JAILLET

Le 22/06/2016 à 22:46, Christophe JAILLET a écrit :

Thx,

it seems that mod_proxy_http2 is missing as well.

Docs are also missing in 2.4 branch and should be added before T, IMHO.
Well, mod_proxy_hcheck.xml exists in 2.4.x, but html files seem to be 
missing.


CJ


Re: AW: mod_proxy_hcheck Compoent in bugzilla

2016-06-22 Thread Christophe JAILLET

Thx,

it seems that mod_proxy_http2 is missing as well.

Docs are also missing in 2.4 branch and should be added before T, IMHO.

CJ

Le 22/06/2016 à 22:39, Plüm, Rüdiger, Vodafone Group a écrit :

Done.

Regards

Rüdiger


-Ursprüngliche Nachricht-
Von: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
Gesendet: Mittwoch, 22. Juni 2016 22:33
An: dev@httpd.apache.org
Betreff: mod_proxy_hcheck Compoent in bugzilla

Hi,

as it will be released soon, mod_proxy_hcheck should be added to
bugzilla's Components list.

I don't remind who to ask for it, so...

CJ





AW: mod_proxy_hcheck Compoent in bugzilla

2016-06-22 Thread Plüm , Rüdiger , Vodafone Group
Done.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
> Gesendet: Mittwoch, 22. Juni 2016 22:33
> An: dev@httpd.apache.org
> Betreff: mod_proxy_hcheck Compoent in bugzilla
> 
> Hi,
> 
> as it will be released soon, mod_proxy_hcheck should be added to
> bugzilla's Components list.
> 
> I don't remind who to ask for it, so...
> 
> CJ
> 



mod_proxy_hcheck Compoent in bugzilla

2016-06-22 Thread Christophe JAILLET

Hi,

as it will be released soon, mod_proxy_hcheck should be added to 
bugzilla's Components list.


I don't remind who to ask for it, so...

CJ




Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

2016-06-22 Thread William A Rowe Jr
On Wed, Jun 22, 2016 at 10:20 AM, William A Rowe Jr 
wrote:

>
> Attached /was/ a patch, now attached again...
>

This patch solves the 80/20... but I'm seeing something disturbing
comparing the
original to the new logic in the new configure output from buildconf...
something
that does not occur with mod_ssl or mod_ldap, which follow the same pattern;

$ diff -u3 configure.orig configure | more
--- configure.orig 2016-06-22 13:36:58.719342545 -0500
+++ configure 2016-06-22 13:37:18.047758290 -0500
@@ -21588,10 +21588,6 @@
   proxy_mods_enable=most
 fi

-if test "$proxy_mods_enable" = "no"; then
-  enable_proxy_hcheck=no
-fi
-
 proxy_objs="mod_proxy.lo proxy_util.lo"

   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to enable
mod_proxy
" >&5
@@ -23327,7 +23323,11 @@
 if test "${enable_proxy_hcheck+set}" = set; then :
   enableval=$enable_proxy_hcheck; force_proxy_hcheck=$enableval
 else
-  enable_proxy_hcheck=$enable_proxy_hcheck
+  enable_proxy_hcheck=$proxy_mods_enable
+  if test "$enable_watchdog" = "no"; then
+enable_proxy_hcheck="";
+  fi
+
 fi

 _apmod_extra_msg=""
@@ -23374,7 +23374,15 @@
   if test "$enable_proxy_hcheck" != "no"; then
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: checking
dependenc
ies" >&5
 $as_echo "checking dependencies" >&6; }
-if test "$enable_watchdog" = "no" ; then
+if test "$enable_proxy" = "no" ; then
+  enable_proxy_hcheck=no
+  { $as_echo "$as_me:${as_lineno-$LINENO}:
WARNING:
 \"mod_proxy is disabled but required for mod_proxy_hcheck\"" >&5
+$as_echo "$as_me: WARNING: \"mod_proxy is disabled but required for
mod_proxy_h
check\"" >&2;}
+elif test "$enable_proxy_hcheck" = "static" &&
test
 "$enable_proxy" != "static" ; then
+  enable_proxy_hcheck=no
+  { $as_echo "$as_me:${as_lineno-$LINENO}:
WARNING:
 \"cannot build mod_proxy_hcheck statically if mod_proxy is built shared\""
>&5
+$as_echo "$as_me: WARNING: \"cannot build mod_proxy_hcheck statically if
mod_pr
oxy is built shared\"" >&2;}
+elif test "$enable_watchdog" = "no" ; then
   enable_proxy_hcheck=no
   { $as_echo "$as_me:${as_lineno-$LINENO}:
WARNING:
 \"mod_watchdog is disabled but required for mod_proxy_hcheck\"" >&5
 $as_echo "$as_me: WARNING: \"mod_watchdog is disabled but required for
mod_prox
y_hcheck\"" >&2;}
@@ -23410,7 +23418,12 @@
   sharedobjs=yes
   shared=yes
   DSO_MODULES="$DSO_MODULES proxy_hcheck"
-  if test "$enable_proxy_hcheck" = "yes" ; then
+  if test "
+  $proxy_mods_enable
+  if test "$enable_watchdog" = "no"; then
+enable_proxy_hcheck="";
+  fi
+" = "yes" ; then
 ENABLED_DSO_MODULES="${ENABLED_DSO_MODULES},proxy_hcheck"
   fi
   ;;

That last stanza is nonsense.

I'm coming to the conclusion that modules/proxy/config.m4 made a fatal error
in not providing the typical no|most|all schema defaults, and that this
resulted
in the obscure behavior in the last stanza.

Have a couple things to wrap up, but I'm coming back to this in about 2 hrs,
and can hopefully isolate why this unique behavior occurs in proxy, but not
in ssl or ldap APACHE_MODULE results.


T 2.4.23 tomorrow (Thurs) ??

2016-06-22 Thread Jim Jagielski
Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).

So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??


Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

2016-06-22 Thread William A Rowe Jr
On Wed, Jun 22, 2016 at 10:19 AM, William A Rowe Jr 
wrote:

> On Wed, Jun 22, 2016 at 7:26 AM, William A Rowe Jr 
> wrote:
>
>>
>>> Have a look at r1749658 & r1749659 for the simplest solution I could
>> come up with, and let me know what you think?
>>
>
> r1749679 improves this a bit further by explaining to the user why
> proxy_hcheck
> isn't built - with a warning that mod_watchdog was disabled.
>
> Attached is a roll-up patch to apply to 2.4.21/.22 to confirm the new
> behavior,
> before 2.4.23 is rolled.
>

Attached /was/ a patch, now attached again...
Index: acinclude.m4
===
--- acinclude.m4	(revision 1748761)
+++ acinclude.m4	(working copy)
@@ -360,13 +360,14 @@
 dnl that may disable it because of missing dependencies.
 ifelse([$6$7],,:,
[AC_MSG_RESULT([checking dependencies])
-ifelse([$7],,:,[if test "$enable_$7" = "no" ; then
+ifelse([$7],,:,[m4_foreach([prereq],[$7],
+   [if test "$enable_[]prereq" = "no" ; then
   enable_$1=no
-  AC_MSG_WARN("mod_$7 is disabled but required for mod_$1")
-elif test "$enable_$1" = "static" && test "$enable_$7" != "static" ; then
+  AC_MSG_WARN("mod_[]prereq is disabled but required for mod_$1")
+elif test "$enable_$1" = "static" && test "$enable_[]prereq" != "static" ; then
   enable_$1=no
-  AC_MSG_WARN("cannot build mod_$1 statically if mod_$7 is built shared")
-else])
+  AC_MSG_WARN("cannot build mod_$1 statically if mod_[]prereq is built shared")
+el])se])
 ifelse([$6],,:,[  $6])
 ifelse([$7],,:,[fi])
 AC_MSG_CHECKING(whether to enable mod_$1)
Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4	(revision 1748761)
+++ modules/proxy/config.m4	(working copy)
@@ -10,10 +10,6 @@
   proxy_mods_enable=most
 fi
 
-if test "$proxy_mods_enable" = "no"; then
-  enable_proxy_hcheck=no
-fi
-
 proxy_objs="mod_proxy.lo proxy_util.lo"
 APACHE_MODULE(proxy, Apache proxy module, $proxy_objs, , $proxy_mods_enable)
 
@@ -63,7 +59,14 @@
 APACHE_MODULE(proxy_balancer, Apache proxy BALANCER module.  Requires and is enabled by --enable-proxy., $proxy_balancer_objs, , $proxy_mods_enable,, proxy)
 
 APACHE_MODULE(proxy_express, mass reverse-proxy module. Requires --enable-proxy., , , $proxy_mods_enable,, proxy)
-APACHE_MODULE(proxy_hcheck, reverse-proxy health-check module. Requires --enable-proxy and --enable-watchdog., , , $enable_proxy_hcheck,, watchdog)
+APACHE_MODULE(proxy_hcheck, [reverse-proxy health-check module. Requires --enable-proxy and --enable-watchdog.], , ,[
+  $proxy_mods_enable
+  dnl Verify that both proxy_mods_enable above and watchdog below are enabled
+  dnl when --enable-proxy-hcheck isn't explicitly elected
+  if test "$enable_watchdog" = "no"; then
+enable_proxy_hcheck="";
+  fi
+], , [proxy,watchdog])
 
 APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])
 


Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

2016-06-22 Thread William A Rowe Jr
On Wed, Jun 22, 2016 at 7:26 AM, William A Rowe Jr 
wrote:

>
>> Have a look at r1749658 & r1749659 for the simplest solution I could
> come up with, and let me know what you think?
>

r1749679 improves this a bit further by explaining to the user why
proxy_hcheck
isn't built - with a warning that mod_watchdog was disabled.

Attached is a roll-up patch to apply to 2.4.21/.22 to confirm the new
behavior,
before 2.4.23 is rolled.

Here's my sanity test under the default --enable-mods-shared=most schema,
throwing all of the proxy, watchdog and proxy_hcheck toggles...

(for h in "--disable-proxy-hcheck" "" "--enable-proxy-hcheck"; do for w in
"--disable-watchdog" "" "--enable-watchdog"; do for p in "--disable-proxy"
"" "--enable-proxy"; do rm Makefile 2>/dev/null; echo "Testing $h $w $p";
../../httpd-2.4/configure $h $w $p 2>&1 | grep hcheck; if test -f Makefile;
then echo "Config complete"; else echo "Config ABORTED"; fi; echo ""; done;
done; done) > logit

The default surprise cases are these two;

Testing  (no flags given)
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_watchdog is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... no (disabled)
Config complete

Testing   --enable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_watchdog is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... no (disabled)
Config complete

it seems to me that now, by default, watchdog aught to be enabled since
it corresponds to the default enablement of proxy and proxy_hcheck, no?
Alternately, --enable-proxy simply has the wrong default for ./configure,
but
I do *not* believe we can or should change that in 2.4.x branch.


Also mildly surprising based on the watchdog default, but entirely harmless,

Testing --enable-proxy-hcheck
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_watchdog is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to
prerequisite failures
Config ABORTED

Testing --enable-proxy-hcheck  --enable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_watchdog is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to
prerequisite failures
Config ABORTED

Post-2.4.21/22 this is now  an informative scenario, and no legacy config
could conceivably toggle --enable-proxy-hcheck, so we can ignore this.


Toggling watchdog leads to desirable default results...

Testing  --enable-watchdog
checking whether to enable mod_proxy_hcheck... checking dependencies
checking whether to enable mod_proxy_hcheck... shared (most)
Config complete

Testing  --enable-watchdog --enable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
checking whether to enable mod_proxy_hcheck... shared
Config complete

Testing --enable-proxy-hcheck --enable-watchdog
checking whether to enable mod_proxy_hcheck... checking dependencies
checking whether to enable mod_proxy_hcheck... shared
Config complete

Testing --enable-proxy-hcheck --enable-watchdog --enable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
checking whether to enable mod_proxy_hcheck... shared
Config complete


Toggling --enable-proxy-hcheck with conflicting arguments leads
to expected, desirably fatal results;

Testing --enable-proxy-hcheck --disable-watchdog --disable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_proxy is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to
prerequisite failures
Config ABORTED

Testing --enable-proxy-hcheck --disable-watchdog
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_watchdog is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to
prerequisite failures
Config ABORTED

Testing --enable-proxy-hcheck --disable-watchdog --enable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_watchdog is disabled but required for
mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... configure: error:
mod_proxy_hcheck has been requested but can not be built due to
prerequisite failures
Config ABORTED

Testing --enable-proxy-hcheck  --disable-proxy
checking whether to enable mod_proxy_hcheck... checking dependencies
configure: WARNING: "mod_proxy is disabled but required for
mod_proxy_hcheck"

Re: svn commit: r1748888 - /httpd/httpd/trunk/modules/proxy/config.m4

2016-06-22 Thread William A Rowe Jr
On Tue, Jun 21, 2016 at 2:33 PM, Ruediger Pluem  wrote:

>
> On 06/21/2016 05:39 PM, William A Rowe Jr wrote:
> > Just retested on 2.4.x branch, better but still problematic...
>
> Would that suit better (against current 2.4.x):
>
> Index: config.m4
> ===
> --- config.m4   (revision 1749588)
> +++ config.m4   (working copy)
> @@ -13,9 +13,17 @@
>  if test "$proxy_mods_enable" = "no"; then
>enable_proxy_hcheck=no
>  fi
> -dnl If enable_proxy_hcheck is unset handle it like other proxy modules
> +dnl If enable_proxy_hcheck is unset handle it like other proxy modules if
> +dnl it is able to disable itself. If not do not enable it.
>  if test -z "$enable_proxy_hcheck" ; then
> -  enable_proxy_hcheck="$proxy_mods_enable"
> +  case "$proxy_mods_enable" in
> +yes|static|shared)
> +  enable_proxy_hcheck=no
> +  ;;
> +*)
> +  enable_proxy_hcheck="$proxy_mods_enable"
> +  ;;
> +  esac
>  fi
>

Have a look at r1749658 & r1749659 for the simplest solution I could
come up with, and let me know what you think?

Off to purge my skull of m4 syntax again with some /r/Eyebleach/


2.4.23

2016-06-22 Thread Jim Jagielski
My plan is to tag T once we get the configure stuff sorted out.


Re: [VOTE] Release Apache httpd 2.4.22 as GA

2016-06-22 Thread Jim Jagielski
I am recalling this VOTE as well.


Re: [VOTE] Release Apache httpd 2.4.22 as GA

2016-06-22 Thread Jim Jagielski

> On Jun 21, 2016, at 10:58 AM, William A Rowe Jr  wrote:
> 
> 
>  
> > On Jun 21, 2016, at 7:39 AM, Jim Jagielski  wrote:
> >
> > Just a reminder for those still testing and/or waiting to cast
> > a vote: One cannot veto a release and even tho OtherBill has
> > voted a someway bi-polar -1, my intent is to, assuming the required
> > 3 or more (binding) +1s, release this despite the diatribe
> > below.
> 
> My mental state, really, Jim? Well, now you know why I sat on the
> fence deciding whether to not vote, and let you eat the eggs of the
> users affected, or vote -1. It took until you re-rolled without any
> feedback for me to get off the fence in defense of those users who
> are adversely impacted by your short-sightedness.
> 

bi-polar *obviously* referred to the *vote*, as syntax and grammar
make clear.

> 
> >>
> >> Given the lengths Jens Schleusener needed to go through to diagnose
> >> this during the original release candidate vote, and the availability of
> >> the patch prior to this tag to fix the RM's own defect (demonstrated
> >> easily with any --enable-modules of few or none, after this community
> >> went to great lengths to re-think the appropriate categorization of all
> >> modules under all/most/few schema) this candidate is clearly not
> >> ready for prime time.
> >>
> >> In all other respects, I see no significant regressions or new issues.
> >> Thanks for RM'ing (2x now)!
> >>
> >>
> >
> 
> 



Re: [VOTE] Release Apache httpd 2.4.22 as GA

2016-06-22 Thread Stefan Eissing
In an ideal world, we'd have test cases for each bug ever found. 
In an ideal world, we'd only call something a regression when we have  a test 
case for it.
In an ideal world, we'd have tireless testers with infinite time to get things 
right.
In an ideal world, we do not have to compromise.

In the real world, we will always have bugs in every release.
In the real world, we should never release something which shows bugs in our 
test suite.
In the real world, if we find bugs without test coverage, we have to weigh 
things.
In the real world, manual tests do not improve on the n-th iteration, as people 
get bored/tired/don't have the time.

In this case, we know of a bug, but have no test case for it.
In this case, it used to work before, but no longer.
In this case, it is not affecting users of the built server.
In this case, there are workarounds for people building httpd (which is a much 
smaller number than users).

Therefore, I vote

+1

on releasing 2.4.22.

PS. I would appreciate if we could pour some of the energy visible here into 
having a build server that just runs some build configurations nightly/weekly. 
2.4.19 failed because of Windows issues, 2.4.22 has hick ups as of build 
configuration issues. Only automation will improve things for the releases to 
come.