On Tue, Jun 21, 2016 at 7:17 AM, Jim Jagielski <j...@jagunet.com> wrote:
> > > On Jun 21, 2016, at 7:56 AM, Plüm, Rüdiger, Vodafone Group < > ruediger.pl...@vodafone.com> wrote: > > > > > > > >> -----Original Message----- > >> From: Jim Jagielski [mailto:j...@jagunet.com] > >> Sent: Dienstag, 21. Juni 2016 13:46 > >> To: dev@httpd.apache.org > >> Subject: Re: svn commit: r1748888 - > >> /httpd/httpd/trunk/modules/proxy/config.m4 > >> > >> 2.4.21 was pulled for a very specific reason and was fixed to > >> address that specific reason... The below will be in 2.4.23 for > >> sure. > >> > >> The question is whether or not to pull/stop 2.4.22... since this > >> isn't a regression per-se, I am leaning towards not unless > >> this issue is larger than it appears... Considering that > >> both trunk and 2.4 have this same build issue and that > >> up until now, no one has brought it up, my thoughts is > >> that it is not common as well. > > > > I think as well that it is not common, but it has been brought up by a > user > > (this was the trigger for me to investigate) and it is a regression in > 2.4.x > > as in 2.4.20 we do not have mod_proxy_hcheck and the same configure that > runs > > there without issue fails with 2.4.22. > > True enough... But, as you say below, if it was a common enough > build setup to hit the bug, we likely would have noticed it > by now since trunk has been this way for awhile... > I guess it wasn't noticed by us prior to the user since I guess most of > us build > > at least --enable-mods-shared=most if not more and it only pops up if > you build less. > Actually no, our builds as devs are far from 'common'. We build, as Rüdiger correctly calls out above, with only all of the features in order to catch all of the bugs. That is a terrific plan until someone fluxors the config.m4 sections. Note especially, ./configure is meant to fail-and-continue, with any missing modules called out for why not (OpenSSL, nghttp2, libxml2 not found... disabling mod_foo). The end result is a compiling if not complete httpd. This is not the behavior of the offending config code introduced in 2.4.21/2.4.22, which is enough to declare the whole thing beta quality. We don't ship 2.4 betas. It was common enough to be called out and ignored by you during the 2.4.21 release vote, which is why my (-0) was promoted to a (-1). If only 2% of the users encounter this defect, and only 10k admins attempt to roll it out, you have 200 people pissed off at your own bad coding. That should be enough for you to consider the wisdom of shipping the broken schema, unless you goal is simply to shove a new module down their throats.
