On Thu, Dec 3, 2015 at 10:32 AM, Nick Kew <n...@apache.org> wrote:
> On Thu, 3 Dec 2015 10:09:08 -0600
> William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> > Most stock/core implementations shouldn't
> > change if a user wants to plug in 'yet another' option, but there is
> > really no excuse for us to map so many ldobjects and text pages into
> > the memory map of a given process, when the actual program text page
> > of each is a few hundred opcodes, max.
>
> Extensibility. Flexibility.
>
> They're our biggest single strength when compared to
> the likes of nginx/tengine.
>
Yup, and I'm not proposing to eliminate the mechanism, I'm proposing
that the existing 'core' subset be codified in fewer, still lightweight
modules.
> > (You can submit that the user could want to replace the bytraffic
> > implementation, for example, but I'd counter that they can certainly
> > rebuild any mod_lbmethod_core module with the others still using
> > stock sources, and deploy their alternative, or they can give their
> > custom fork of a provide yet another provider name.)
>
> Someone wanting different functionality shouldn't have to
> take on the maintenance headache of hacking into one of
> our modules. We have our API/ABI promise to make life easy
> for them introducing their own modules.
>
If they are *replacing* our tokens, that's on them. They can add their
own lbname, e.g. bytraffic-hacked, without rebuilding a core provider.
And I'm not going to propose any of this for backport, in fact I don't plan
to condense the source files at all, only simplify their hook registration
and compile the several providers under a core module umbrella.
> I'm not asking anyone to coalesce these, though. It was already
> > on my rather long list of 'nice to have' along with supporting
> > multiple conf mergers per module (effectively allowing 'multiple
> > modules' to be a single module and splitting our monstrous core
> > server and dir configs into related digestible pieces that rarely
> > need to be merged, and optimizing away modules with no conf merge at
> > all). And along with cleaning up the httpd 2.next API, and i18n of
> > error output which I am continuing on first once the mod_ssl issues
> > for mod_ftp are resolved (my current project).
>
> Hmmm. There's some nice-to-have in there, but it also sounds like
> a big hack.
>
Actually they are the ideas and justifications;
1. multiple conf sections) right now, a module such as core or mod_ssl
has a small subset of "key" config directives that change often,
perhaps in nearly every <VirtualHost > block or <Directory > level.
Then there is a majority of directives that never change from either
the global or first-triggered block (e.g. toggling auth from denied to
a site-wide global permitted state). These are merges that just
should not have to happen on each and every merge. Directory is
obviously the worst offender, while Server blocks are merged at
startup and don't enjoy nearly as much optimization. Dropping
any module from the merge list that has a NULL merge should
speed up directory merges, too. Unsuitable for backport.
2. API cleanup) I'm looking at a util_compat.h that would map all of
our long-deprecated ap_ functions into their apr_ or newer _ex
equivalents. And busting up httpd.h, starting with util_strings.h
Unsuitable for backport.
3. i18n) You ask about our "strengths", we have little globally until
we actually internationalize error output. Most servers beat us
a long time ago in this respect. Errors are more confusing than
learning the few tokens you need to write a config (however, some
internationalized .conf.in files for descriptive text would be a help.)
The specific error lookup has can be overridden per-server, giving
shared hosting providers the ability to let vhost admins grok the
errors their site is receiving. It's nothing more than a hash table
now that we have decorated APnnnnn throughout the 2.x and 2.4
error output, so this one can be considered for backport.
4. mod_ssl) yes, I know my last Upgrade: TLS/1.0 patch doesn't
interact with the Protocols directive and h2c, since Protocols
directive patch failed to pick up the existing mod_ssl Upgrade/
Connection logic. Working on that fix right now so that both
options present just one unified Upgrade/Connection message.
That fix aught to be backported for completeness.
5. mod_ftp) several recent mod_ssl changes busted mod_ftp's
AUTH TLS support - and possibly due to my implicit HOST
command hack (the result of a HOST command is the same
221 welcome as an initial connection, so this was a fakeout
to cause that initial greeting - based on the SNI hostname in
the case of explicit SSL.) Both the implicit port 995 and
plaintext port 21 flavors were and are still working, so it is
just a matter of better coupling mod_ftp AUTH TLS to the
upgrade mechanisms of mod_ssl. Hopefully minimal or no
core mod_ssl changes are needed.
I'm looking, none of these seem like huge hacks, wondering
which of them trigger your concern?
Cheers,
Bill
