AW: Current trunk win build error

Looks better than mine, but as we register the function with a different name we need to adjust the parameter to the APR_RETRIEVE_OPTIONAL_FN macro in all mod_lbmethod modules as I did, correct? Regards Rüdiger Von: William A Rowe Jr Gesendet: Montag, 23. Juli 2018 16:54 An: httpd Betreff:

Re: Current trunk win build error

Seeing "Rüdiger" (Hello!), "proxy_util" and "win" compels me to ask: Is this in any way related to [1] too? Should I be playing with this patch as well? How come you get pass the mod_http2 error with proxy_util.c? I hope the thread won't  catch on fire in CMake/.dsp/.sln/.vcxproj flames :) [1]

Re: Current trunk win build error

I think it's simply the attached (couldn't apply the inline text patch). No need to change the hook name. On Mon, Jul 23, 2018 at 9:16 AM, Plüm, Rüdiger, Vodafone Group < ruediger.pl...@vodafone.com> wrote: > So something like the below? > > > > Regards > > > > Rüdiger > > > > Index:

AW: Current trunk win build error

So something like the below? Regards Rüdiger Index: modules/proxy/balancers/mod_lbmethod_bybusyness.c === --- modules/proxy/balancers/mod_lbmethod_bybusyness.c (revision 1836460) +++

Re: Current trunk win build error

Perhaps use proxy_balancer_get_best_worker, and don't export that? That can be the delegate for ap_proxy_balancer_get_best_worker. We either keep callbacks local, or export them _NONSTD. All the *_DECLARE (without _NONSTD) are not usable as apr/httpd callbacks. On Mon, Jul 23, 2018 at 7:22 AM,

AW: Current trunk win build error

> -Ursprüngliche Nachricht- > Von: Apache Lounge > Gesendet: Montag, 23. Juli 2018 13:35 > An: dev@httpd.apache.org > Betreff: Current trunk win build error > > > > > > Error C2440 'initializing': cannot convert from 'proxy_worker > *(__stdcall *)(proxy_balancer *,request_rec >

Current trunk win build error

Error C2440 'initializing': cannot convert from 'proxy_worker *(__stdcall *)(proxy_balancer *,request_rec *,proxy_is_best_callback_fn_t (__cdecl *),void *)' to 'apr_OFN_ap_proxy_balancer_get_best_worker_t (__cdecl *)' mod_proxy c:\vc15\win32\httpd-trunk\modules\proxy\proxy_util.c 4082

Re: mod_ssl and openssl 1.0.2 initialization

Well, if a auto-loaded core_ssl module publishes an optional ap_ssl_crypto_init() function, mod_md would sure like to call that. Cheers, Stefan > Am 23.07.2018 um 12:25 schrieb Yann Ylavic : > > On Mon, Jul 23, 2018 at 12:05 PM, Plüm, Rüdiger, Vodafone Group > wrote: >> >>> Von: Yann

Re: mod_ssl and openssl 1.0.2 initialization

On Mon, Jul 23, 2018 at 12:05 PM, Plüm, Rüdiger, Vodafone Group wrote: > >> Von: Yann Ylavic >> >> Yes, I agree that we have an issue with openssl (< 1.1) >> loading/unloading/initialization for different modules: core, mod_ssl, >> mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of

Re: mod_ssl and openssl 1.0.2 initialization

On Mon, Jul 23, 2018 at 11:50 AM, Yann Ylavic wrote: > > I started to try to centralize openssl setup in APR (r1833421, but I'm > being cautious here because it kind of has been reverted lately...). > What do you think of an 'apr_crypto_lib_init("openssl", ..., pool)' > call from any module,

AW: mod_ssl and openssl 1.0.2 initialization

> -Ursprüngliche Nachricht- > Von: Yann Ylavic > Gesendet: Montag, 23. Juli 2018 11:50 > An: httpd-dev > Betreff: Re: mod_ssl and openssl 1.0.2 initialization > > On Wed, Jul 18, 2018 at 3:14 PM, Stefan Eissing > wrote: > > Something fishy reported in > >

Re: mod_ssl and openssl 1.0.2 initialization

On Wed, Jul 18, 2018 at 3:14 PM, Stefan Eissing wrote: > Something fishy reported in > https://bz.apache.org/bugzilla/show_bug.cgi?id=62552 > > Which points to a problem with CRYPTO_THREADID and crypto locks and > initialization oder in OpenSSL 1.0.2. (I believe OpenSSL 1.1.x > eleminated that).

Re: ocsp_force_default initialized with UNSET in httpd 2.4.34

Thanks! > Am 23.07.2018 um 11:27 schrieb Plüm, Rüdiger, Vodafone Group > : > >

AW: ocsp_force_default initialized with UNSET in httpd 2.4.34

Wrong revision. Correct one is r1836472. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Plüm, Rüdiger, Vodafone Group > Gesendet: Montag, 23. Juli 2018 11:26 > An: dev@httpd.apache.org > Betreff: AW: ocsp_force_default initialized with UNSET in httpd 2.4.34 > > This is now

AW: ocsp_force_default initialized with UNSET in httpd 2.4.34

This is now backported to 2.4.x as r1555631 and will be part of the next release. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Frank Meier > Gesendet: Freitag, 20. Juli 2018 09:26 > An: dev@httpd.apache.org > Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34

AW: Bug in mod_ratelimit?

> -Ursprüngliche Nachricht- > Von: Yann Ylavic > Gesendet: Montag, 23. Juli 2018 10:52 > An: httpd-dev > Betreff: Re: Bug in mod_ratelimit? > > On Mon, Jul 23, 2018 at 7:45 AM, Plüm, Rüdiger, Vodafone Group > wrote: > > > > > >> -Ursprüngliche Nachricht- > >> Von: Eric

Re: Bug in mod_ratelimit?

On Mon, Jul 23, 2018 at 7:45 AM, Plüm, Rüdiger, Vodafone Group wrote: > > >> -Ursprüngliche Nachricht- >> Von: Eric Covener >> Gesendet: Sonntag, 22. Juli 2018 21:58 >> An: Apache HTTP Server Development List >> Betreff: Re: Bug in mod_ratelimit? >> >> > > You probably didn't test with

AW: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/

Von: William A Rowe Jr Gesendet: Freitag, 20. Juli 2018 23:03 An: httpd Betreff: Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/ On Fri, Jul 20, 2018, 15:22 Ruediger Pluem wrote: BTW: We have the same load