httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: reverse proxy wishlist
Date Fri, 04 Dec 2015 16:40:42 GMT
On Fri, Dec 4, 2015 at 10:17 AM, Nick Kew <nick@webthing.com> wrote:

>
> > I'm looking, none of these seem like huge hacks, wondering
> > which of them trigger your concern?
>
> Well, your talk of refactoring config led me to wonder
> whether you were proposing another tilt at the whole directory
> walk stuff.  While that may have merit, past experience
> tells us it's not going to be easy!
>

If I never have to refactor that code again, it will still be too soon :-/

More likely that someone enthusiastic could take the base/short
unique <Directory> blocks and pre-merge those to global/vhost
scope, as the shortcut to a more specific scope as the first-match
hit.  Deeper pre-merge optimizations would be rough and all of it
presupposes there are no request-specific eval blocks and no
directory permitting an .htaccess could be optimized that way.

So... no... much like the non-iterating fnmatch implementation, I'd
prefer to let others wrap their heads around that puzzle and come
up with something new and more efficient.  All I was thinking of
doing was extending the core concept of 'compiled in modules'
to allow a module-of-modules, and build unique create/merge
call tables at the end of register_hooks, instead of the slightly
odd way we we presume that each module does or does not have
one of each such creater/merger, skipping along the NULL refs.

When we last tried to optimize this, hooks were attempted and
proved to have much too much overhead. A startup-time straight
array of function pointer/conf index pointer elements will be
the only way to keep the logic as efficient as it is today, and
then build upon that model.  I don't expect we will allow the
create/merge table to change after the register_hooks phase.

Mime
View raw message