On Sat, 02 Feb 2013 13:18:11 -0800
Gregg Smith <[email protected]> wrote:
> Hello,
>
> Since the Next Protocol Negotiation addition, mod_ssl cannot be
> compiled on Windows since the AP namespace is for imports.
>
> Are there any objections to this which allows the NPN hooks to be
> exported in
> Windows.
>
> If there are no objection I'll commit this in a few days.
Here is from branches/2.2.x/STATUS for the past year;
* mod_ssl: Add support for Next Protocol Negotiation.
Trunk patch:
http://svn.apache.org/viewvc?view=revision&revision=1332643
2.2.x patch:
http://www.links.org/files/npn-patch-2.2.patch
+1: benl
sf notes: needs the buffer overflow fix from r1345599, too
wrowe notes: also needs correction to
ssl_engine_kernel.c: In function 'ssl_callback_AdvertiseNextProtos':
ssl_engine_kernel.c:2140:5: warning: implicit declaration of function
'modssl_run_npn_advertise_protos_hook'
Including mod_ssl.h after ssl_private.h seems to suffice.
The change introduces hard linkages from modules into
mod_ssl.so (distinct from httpd), AP is the incorrect
namespace, see mod_dav main hooks as an example.
Prior to this patch all calls to mod_ssl were by way of
registered functions through apr bindings. Seems there
aught to be a way to add an npn cooperating module when
mod_ssl is not loaded, but right now it would fail.
An mmn minor bump would also be required for API addition.
In short, the whole thing is an misdesign in the first place. A new
registered function is required to hook from core back into mod_ssl
without always loading mod_ssl in a specific order. (And those would
not have have become typesafe without some of Ben's C-language abuse
and brilliance).
I know many of us miss some of the simplicity of httpd 1.3, but the
module load order mess is not something to restore, eh?
