On Sat, Apr 14, 2018 at 9:48 AM, Jim Jagielski <j...@jagunet.com> wrote:
> IMO, the below ignores the impacts on OS distributors who
> provide httpd. We have seen how long it takes for them
> to go from 2.2 to 2.4... I can't imagine the impact for our
> end user community if "new features" cause a minor
> bump all the time and we "force" distributions for
> 2.4->2.6->2.8->2.10...
>
> Just my 2c
>
>
That also assumes the OS distributions pick up the point releases. RedHat
certainly doesn't pick up the new features, only bug fixes.
- Y
> > On Apr 13, 2018, at 2:28 PM, David Zuelke <dzue...@salesforce.com>
> wrote:
> >
> > Remember the thread I started on that quite a while ago? ;)
> >
> > IMO:
> >
> > - x.y.0 for new features
> > - x.y.z for bugfixes only
> > - stop the endless backporting
> > - make x.y.0 releases more often
> > - x.y.0 goes through alpha, beta, RC phases
> > - x.y.z goes through RC phases
> >
> > That's how PHP has been doing it for a few years, and it's amazing how
> > well it works, how few regressions there are, and how predictable the
> > cycle is (they cut an x.y.zRC1 every four weeks like clockwork, with
> > exceptions only around late December because of holiday season).
> >
> > This would also fix all the confusing cases where two or three faulty
> > releases get made, end up in the changelog, but ultimately are never
> > released.
> >
> >
> > On Fri, Apr 13, 2018 at 5:28 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >> Terrific analysis! But on the meta-question...
> >>
> >> Instead of changing the behavior of httpd on each and every subversion
> bump,
> >> is it time to revisit our revisioning discipline and hygiene?
> >>
> >> I promise to stay out of such discussion provided that one equally
> stubborn
> >> and intractable PMC member agrees to do the same, and let the balance
> of the
> >> PMC make our decision, moving forwards.
> >>
> >> On Fri, Apr 13, 2018, 06:11 Joe Orton <jor...@redhat.com> wrote:
> >>>
> >>> On Thu, Apr 12, 2018 at 09:38:46PM +0200, Ruediger Pluem wrote:
> >>>> On 04/12/2018 09:28 AM, Joe Orton wrote:
> >>>>> But logged is:
> >>>>>
> >>>>> ::1 - - [12/Apr/2018:08:11:12 +0100] "GET /agag HTTP/1.1" 404 12
> >>>>> HTTPS=on SNI=localhost.localdomain
> >>>>> 127.0.0.1 - - [12/Apr/2018:08:11:15 +0100] "GET /agag HTTP/1.1" 404
> 12
> >>>>> HTTPS=- SNI=-
> >>>>>
> >>>>> Now mod_ssl only sees the "off" SSLSrvConfigRec in the second vhost
> so
> >>>>> the logging is wrong.
> >>>>
> >>>> What does the same test result in with 2.4.29?
> >>>
> >>> Excellent question, I should have checked that. Long e-mail follows,
> >>> sorry.
> >>>
> >>> In fact it is the same with 2.4.29, because the SSLSrvConfigRec
> >>> associated with the vhost's server_rec is the same as the default/base
> >>> (non-SSL) server_rec, aka base_server passed to post_config hooks aka
> >>> the ap_server_conf global.
> >>>
> >>> So, maybe I understand this a bit better now.
> >>>
> >>> Config with three vhosts / server_rec structs:
> >>> a) base server config :80 non-SSL (<-- ap_server_conf/base_server)
> >>> b) alpha vhost :443, explicit SSLEngine on, SSLCertificateFile etc
> >>> c) beta vhost :443, no SSL*
> >>>
> >>> For 2.4.29 mod_ssl config derived is:
> >>> a) SSLSrvConfigRec for base_server = { whatever config at global scope
> }
> >>> b) SSLSrvConfigRec for alpha = { sc->enabled = TRUE, ... }
> >>> c) SSLSrvConfigRec pointer for beta == SSLSrvConfigRec for base_server
> >>> in the lookup vector (pointer is copied prior to ALWAYS_MERGE flag)
> >>>
> >>> For 2.4.33 it is:
> >>> a) and b) exactly as before
> >>> c) separate SSLSrvConfigRec for beta = { merged copy of config at
> global }
> >>> time because of the ALWAYS_MERGE flag, i.e. still sc->enabled = UNSET
> >>>
> >>> When running ssl_init_Module(post_config hook), with 2.4.29:
> >>> - SSLSrvConfig(base_server)->enabled = FALSE because UNSET previously
> >>> - SSLSrvConfig(base_server)->vhost_id gets overwritten with vhost_id
> >>> for beta vhost because it's later in the loop and there's no check
> >>>
> >>> And with 2.4.33:
> >>> - SSLSrvConfig(beta)->enabled is UNSET but gets flipped to ENABLED,
> >>> then startup fails (the issue in question)
> >>>
> >>> w/my patch for 2.4.33:
> >>> - SSLSrvConfig(beta)->enabled is FALSE and startup works
> >>>
> >>> At run-time a request via SSL which matches the beta vhost via
> SNI/Host:
> >>>
> >>> For 2.4.29:
> >>> - r->server is the beta vhost and mySrvConfig(r->server) still gives
> >>> you the ***base_server*** SSLSrvConfigRec i.e. sc->enabled=FALSE
> >>> - thus e.g. ssl_hook_Fixup() does nada
> >>>
> >>> For 2.4.33 plus my patch:
> >>> - r->server is the beta vhost and mySrvConfig(r->server) gives
> >>> you the SSLSrvConfigRec which is also sc->enabled = FALSE
> >>> - thus e.g. ssl_hook_Fixup() also does nada
> >>>
> >>> I was trying to convince myself whether mySrvConfig(r->server) is going
> >>> to change between 2.4.29 and .33+patch in this case, and I think it
> >>> should be identical, because it is *only* the handling of ->enabled
> >>> which has changed with _ALWAYS_MERGE.
> >>>
> >>> TL;DR:
> >>> 1. my head hurts
> >>> 2. I think my patch is OK
> >>>
> >>> Anyone read this far?
>
>
