Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Tue, 5 Feb 2013 11:52:24 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
To: dev@httpd.apache.org
Cc: gls@gknw.net
Subject: Re: trunk/mod_ssl and Windows
Message-ID: <20130205115224.33547872@hub>
In-Reply-To: <510D8293.8010103@gknw.net>
References: <510D8293.8010103@gknw.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 02 Feb 2013 13:18:11 -0800
Gregg Smith <gls@gknw.net> 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?