httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rich" <>
Subject Re: svn commit: r440337 - in /httpd/httpd/trunk: ./ include/ modules/arch/netware/ modules/experimental/ modules/generators/ modules/http/ modules/mappers/ modules/proxy/ modules/ssl/ server/ server/mpm/beos/ server/mpm/experimental/event/ server/mpm
Date Tue, 05 Sep 2006 21:09:23 GMT
Hash: SHA1

On Tue, 05 Sep 2006 22:00:59 +0100 Jeff Trawick <>
>On 9/5/06, Ruediger Pluem <> wrote:
>> On 09/05/2006 03:08 PM, wrote:
>> > Author: trawick
>> > Date: Tue Sep  5 06:08:15 2006
>> > New Revision: 440337
>> >
>> > URL:
>> > Log:
>> > Replace ap_get_server_version with ap_get_server_banner() and
>> > ap_get_server_description().
>> Two comments:
>> 1. If we stick to
>> AP_DECLARE(const char *) ap_get_server_version(void);
>> and do
>> #define ap_get_server_banner ap_get_server_version
>> I guess we can backport this without breaking binary
>compatibility and the need
>> for a major bump (on trunk the major bump makes sense to me).
>Given the fact that
>> we want to calm certain FAQ requests it would make sense to me
>to backport it.
>I'm hoping to backport it even if just to stop maintaining my own
>patch to get juicy info in the error log at startup when the user
>"ServerTokens Prod" ;)
>I'd go with Brian's plan to preserve ap_get_server_version().  It
>allows modules to do the right thing (call the function specific
>what they're trying to do) for Apache >= 2.2.4.  They can use the
>function for compatibility or the new function if it helps them.
>> 2. On trunk shouldn't we add
>> #define ap_get_server_version ap_get_server_banner
>my 2 cents: for trunk, we'd like third-party modules to go ahead
>decide which API to call based on what they are doing with the
>information; if they still load fine courtesy of a macro or
>ap_get_server_version() function, some folks will miss that giant
>include/ap_compat.h might be the place to put a macro definition
>compatibility (even though it says compatibility with 1.3 in the
>> While this still breaks binary compatibility it would allow
>modules using ap_get_server_version
>> to compile against trunk. Maybe we could mark
>ap_get_server_version as deprecated on trunk.
>> I am not a macro expert, but maybe it is even possible to spit
>out a warning if ap_get_server_version
>> is used.
>> Thoughts?
>I think we'd mark it deprecated on 2.2.x branch if/when we
>the new APIs and it simply disappears on trunk.
>I'm anxious to hear more opinions.
Note: This signature can be verified at
Version: Hush 2.5


Concerned about your privacy? Instantly send FREE secure email, no account required

Get the best prices on SSL certificates from Hushmail

View raw message