httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rich" <learnb...@hushmail.com>
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Tue, 05 Sep 2006 22:00:59 +0100 Jeff Trawick <trawick@gmail.com>
wrote:
>On 9/5/06, Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>
>> On 09/05/2006 03:08 PM, wrote:
>> > Author: trawick
>> > Date: Tue Sep  5 06:08:15 2006
>> > New Revision: 440337
>> >
>> > URL: http://svn.apache.org/viewvc?view=rev&rev=440337
>> > 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
>has
>"ServerTokens Prod" ;)
>
>I'd go with Brian's plan to preserve ap_get_server_version().  It
>also
>allows modules to do the right thing (call the function specific
>to
>what they're trying to do) for Apache >= 2.2.4.  They can use the
>old
>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
>and
>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
>hint
>
>include/ap_compat.h might be the place to put a macro definition
>for
>compatibility (even though it says compatibility with 1.3 in the
>doc)
>
>> 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
>backport
>the new APIs and it simply disappears on trunk.
>
>I'm anxious to hear more opinions.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wpwEAQECAAYFAkT954MACgkQBHmU+brPI+zocQP/bje5dYTBSjJ99VUGY8HR4rjqTvQO
o09z9D2uIWzQZkXt9X88e8B3Ca77sPI9QZbZg7n5OUcMZU/E1y6ETuOvT2OKmJtehbCk
z22lYEv5PSwJHK1QpRbIqj31juSv/41QGWkdKCeefi7k33rWNYgwjK0fVMHQY8W+R0Da
2mPDNcU=
=Pd1q
-----END PGP SIGNATURE-----




Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485


Mime
View raw message