Re: New Mod_Proxy - some testing/looking
Good morning Brad, Thanks for knocking on the httpd.apache.org door the latest updates now work all the way through to apache2.nlm without issue... can now see what I can do with the nlm's. Give a regards to the commiters at devAThttpd.apache.org. Norm >From what I can see, there seems to be a parameter mismatch for the > scheme_handler hook. For example, the scheme_handler > ap_proxy_connect_handler() is defined as: > > int ap_proxy_connect_handler(request_rec *r, proxy_server_conf *conf, > char *url, const char *proxyname, > apr_port_t proxyport) > > but the scheme_handler hook is defined as: > > APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, scheme_handler, > (request_rec *r, > proxy_worker *worker, proxy_server_conf > *conf, char *url, > const char *proxyhost, apr_port_t > proxyport)) > > notice the difference in the parameter lists. The declaration has 6 > parameters and the actual handler only has 5. The handler is missing > proxy_worker * as the second parameter. How does this compile or even > work on any platform? > > Brad > > > Brad Nicholes > Senior Software Engineer > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > >>> [EMAIL PROTECTED] Friday, August 13, 2004 1:37:16 PM >>> > At 04:58 AM 8/13/2004, NormW wrote: > >Good evening Bill, All... > > > >> Please direct these comments to [EMAIL PROTECTED] - b.t.w., you > >> can check out the latest httpd-2.0 HEAD and pick up the entire > proxy > >> solution (you must explicitly --enable-proxy-ajp and have the > ajplib > >> sources there too.) > >> > >> Someone want to take a wack at NormW's observations? > >Bill, thanks for the interest... > >I can say that the 'problem' noted in proxy_ftp.c has been attended > with a > >recent update from Mladen. > >A build on the current 2.1 CVS shows (for NetWare): > >- mod_proxy.c having trouble finding mod_status.h (in > >../modules/generators), > >- the same problem mentioned previously with proxy_connect.c, (Errors > at 375 > >see 26, 80) > >Bypassing these I now get: > >Calling NWGNUproxyftp > >Generating Release\proxyftp_cc.opt > >Compiling proxy_ftp.c > >Compiling proxy_util.c > >Compiling ../arch/netware/libprews.c > >Generating Release\proxyftp_link.opt > >Linking Release/proxyftp.nlm > >### mwldnlm Linker Error: > ># Undefined symbol: 'ap_proxy_ssl_enable' > ># referenced from 'ap_proxy_connection_create' in proxy_util.o > >### mwldnlm Linker Error: > ># Undefined symbol: 'ap_proxy_ssl_disable' > ># referenced from 'ap_proxy_connection_create' in proxy_util.o > > > >As noted above, this is on a NetWare build... > > It's expected because the netware gurus haven't had a chance to > catch up. Please quit using tomcat-dev already - final warning; > ignoring future posts to there in order to enforce posting future > proxy patches/comments to [EMAIL PROTECTED] ;-) > > I suspect Netware didn't grok that those symbols were local/global > as required? > > Bill > > >
Re: New Mod_Proxy - some testing/looking
From what I can see, there seems to be a parameter mismatch for the scheme_handler hook. For example, the scheme_handler ap_proxy_connect_handler() is defined as: int ap_proxy_connect_handler(request_rec *r, proxy_server_conf *conf, char *url, const char *proxyname, apr_port_t proxyport) but the scheme_handler hook is defined as: APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, scheme_handler, (request_rec *r, proxy_worker *worker, proxy_server_conf *conf, char *url, const char *proxyhost, apr_port_t proxyport)) notice the difference in the parameter lists. The declaration has 6 parameters and the actual handler only has 5. The handler is missing proxy_worker * as the second parameter. How does this compile or even work on any platform? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, August 13, 2004 1:37:16 PM >>> At 04:58 AM 8/13/2004, NormW wrote: >Good evening Bill, All... > >> Please direct these comments to [EMAIL PROTECTED] - b.t.w., you >> can check out the latest httpd-2.0 HEAD and pick up the entire proxy >> solution (you must explicitly --enable-proxy-ajp and have the ajplib >> sources there too.) >> >> Someone want to take a wack at NormW's observations? >Bill, thanks for the interest... >I can say that the 'problem' noted in proxy_ftp.c has been attended with a >recent update from Mladen. >A build on the current 2.1 CVS shows (for NetWare): >- mod_proxy.c having trouble finding mod_status.h (in >../modules/generators), >- the same problem mentioned previously with proxy_connect.c, (Errors at 375 >see 26, 80) >Bypassing these I now get: >Calling NWGNUproxyftp >Generating Release\proxyftp_cc.opt >Compiling proxy_ftp.c >Compiling proxy_util.c >Compiling ../arch/netware/libprews.c >Generating Release\proxyftp_link.opt >Linking Release/proxyftp.nlm >### mwldnlm Linker Error: ># Undefined symbol: 'ap_proxy_ssl_enable' ># referenced from 'ap_proxy_connection_create' in proxy_util.o >### mwldnlm Linker Error: ># Undefined symbol: 'ap_proxy_ssl_disable' ># referenced from 'ap_proxy_connection_create' in proxy_util.o > >As noted above, this is on a NetWare build... It's expected because the netware gurus haven't had a chance to catch up. Please quit using tomcat-dev already - final warning; ignoring future posts to there in order to enforce posting future proxy patches/comments to [EMAIL PROTECTED] ;-) I suspect Netware didn't grok that those symbols were local/global as required? Bill
Re: New Mod_Proxy - some testing/looking
At 04:58 AM 8/13/2004, NormW wrote: >Good evening Bill, All... > >> Please direct these comments to [EMAIL PROTECTED] - b.t.w., you >> can check out the latest httpd-2.0 HEAD and pick up the entire proxy >> solution (you must explicitly --enable-proxy-ajp and have the ajplib >> sources there too.) >> >> Someone want to take a wack at NormW's observations? >Bill, thanks for the interest... >I can say that the 'problem' noted in proxy_ftp.c has been attended with a >recent update from Mladen. >A build on the current 2.1 CVS shows (for NetWare): >- mod_proxy.c having trouble finding mod_status.h (in >../modules/generators), >- the same problem mentioned previously with proxy_connect.c, (Errors at 375 >see 26, 80) >Bypassing these I now get: >Calling NWGNUproxyftp >Generating Release\proxyftp_cc.opt >Compiling proxy_ftp.c >Compiling proxy_util.c >Compiling ../arch/netware/libprews.c >Generating Release\proxyftp_link.opt >Linking Release/proxyftp.nlm >### mwldnlm Linker Error: ># Undefined symbol: 'ap_proxy_ssl_enable' ># referenced from 'ap_proxy_connection_create' in proxy_util.o >### mwldnlm Linker Error: ># Undefined symbol: 'ap_proxy_ssl_disable' ># referenced from 'ap_proxy_connection_create' in proxy_util.o > >As noted above, this is on a NetWare build... It's expected because the netware gurus haven't had a chance to catch up. Please quit using tomcat-dev already - final warning; ignoring future posts to there in order to enforce posting future proxy patches/comments to [EMAIL PROTECTED] ;-) I suspect Netware didn't grok that those symbols were local/global as required? Bill
Re: New Mod_Proxy - some testing/looking
Please direct these comments to [EMAIL PROTECTED] - b.t.w., you can check out the latest httpd-2.0 HEAD and pick up the entire proxy solution (you must explicitly --enable-proxy-ajp and have the ajplib sources there too.) Someone want to take a wack at NormW's observations? At 02:31 AM 8/11/2004, NormW wrote: >Greetings All, > >1. The testing. > >Trying a build of the current CVS of the new (ajp) proxy modules and get the >following error: > >#File: proxy_ftp.c ># >#1896: proxy_hook_scheme_handler(ap_proxy_ftp_handler, NULL, NULL, >APR_HOOK_MIDDLE); ># Error: >^ ># illegal implicit conversion from 'int (struct request_rec *, struct *, >char *, const char *, unsigned short)' to ># 'int (*)(struct request_rec *, struct proxy_worker *, struct *, char *, >const char *, unsigned short)' > >There is a similar issue in proxy_connect.c at line 374. > >The one module that does build without issue is proxy_http.c. > >A check of the coding in proxy_http.c shows a handler structure of: >int ap_proxy_http_handler(request_rec *r, > proxy_worker *worker, > proxy_server_conf *conf, > char *url, > const char *proxyname, > apr_port_t proxyport); > >whereas those in proxy_ftp and proxy_connect.c have: >int ap_proxy_ftp_handler(request_rec *r, > proxy_server_conf *conf, > char *url, > const char *proxyhost, > apr_port_t proxyport); > > >If I add the "proxy_worker *worker" to both proxy_ftp and proxy_connect >structures they build without issue. >Any comments please? > >2. The looking. > >In proxy_ftp.c, can the "const char *proxyhost" be changed to "const char >*proxyname" for consistency please? > >Regards, >Norm > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED]
