Re: svn commit: r1086073 - in /httpd/httpd/trunk: ./ include/ modules/cache/ os/netware/ os/win32/ server/ server/mpm/netware/ server/mpm/winnt/
On Mon, Mar 28, 2011 at 12:35 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/27/2011 7:39 PM, Guenter Knauf wrote: Am 28.03.2011 01:57, schrieb Jeff Trawick: On Sun, Mar 27, 2011 at 7:51 PM,traw...@apache.org wrote: Author: trawick Date: Sun Mar 27 23:51:18 2011 New Revision: 1086073 URL: http://svn.apache.org/viewvc?rev=1086073view=rev Log: enable DEFAULT_REL_RUNTIMEDIR on NetWare and Windows this commit is missing the Windows and NetWare build logic to copy the appropriate file to include/ap_config_layout.h just so the info isn't trapped inside another thread: Windows: a change is needed (perhaps to libhttpd.dsp) to copy os/win32/win32_config_layout.h to include/ap_config_layout.h NetWare: something similar with other headers we do usually just append w|nw to the extensision, and have these files in same directory as where the target should live, f.e.: include/ap_config_layout.h (target) include/ap_config_layout.hw (windows) include/ap_config_layout.hnw (netware) then at least for NetWare where we use GNU make a simple generic rule: %.h : %.hnw copy $ $@ does the job (we use this already with APR/APU too) ... I dont say that the copy with those files you commited is of any problem, just wanted to mention what existing logic we currently have already with other headers ... awaiting Bill's comment on that ... FWLIW, I thought of that, but decided not to when I found no .hw or .hnw within httpd. Go for it! +/-0, I'm happy either way, I'll commit the build update in the morning whether the source file is named os_layout.h or ap_config_layout.hw :)
Re: [PATCH] default_rel_runtimedir everywhere (Windows, NetWare)
On Mon, Mar 28, 2011 at 12:51 AM, NormW no...@gknw.net wrote:
On 28/03/2011 10:41 AM, NormW wrote:
On 28/03/2011 9:54 AM, Jeff Trawick wrote:
On Sun, Mar 27, 2011 at 6:09 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
On 3/27/2011 10:30 AM, Jeff Trawick wrote:
Concerns (such as better name for the new file)?
Only one... please don't add #include logic, let Gunter and I wire up
the auto-copy to ap_config_layout.h and we will truly be consistent.
You can update the patch to assume that file always exists. Let's keep
the main .c code as absolutely consistent as possible with fewer
per-arch
variations.
ap_config.h now unconditionally includes ap_config_layout.h.
I renamed the two OS-specific, non-autoconf-build versions to
{win32,netware}_config_layout.h to make it obvious to lurkers that
they should not include this file as present in the os directory.
A patch to httpd-trunk similar to the following does the trick (on NetWare
at least).
Index: include/ap_config.h
===
--- include/ap_config.h (revision 1086115)
+++ include/ap_config.h (working copy)
@@ -232,8 +232,12 @@
#include os.h
#if (!defined(WIN32) !defined(NETWARE)) || defined(__MINGW32__)
#include ap_config_auto.h
+#include ap_config_layout.h
+#elif defined(NETWARE)
+#include netware_config_layout.h
+#elif defined(WIN32)
+#include win32_config_layout.h
#endif
-#include ap_config_layout.h
#if defined(NETWARE)
#define AP_NONBLOCK_WHEN_MULTI_LISTEN 1
Thanks, but as per wrowe's suggestion the file
(netware_config_layout.h or ap_config_layout.hnw if renamed) will get
copied to ap_config_layout.h, so that the one #include of
ap_config_layout.h will work for all platforms.
(ap_config_layout.h for Unix is generated anyway.)
Re: svn commit: r1086073 - in /httpd/httpd/trunk: ./ include/ modules/cache/ os/netware/ os/win32/ server/ server/mpm/netware/ server/mpm/winnt/
Hi Jeff, Am 28.03.2011 12:24, schrieb Jeff Trawick: FWLIW, I thought of that, but decided not to when I found no .hw or .hnw within httpd. Go for it! I adopted Bill's EDONTCARE mode, and went your way already :-) http://svn.apache.org/viewvc?view=revisionrevision=1086122 Gün.
Re: Plan for next beta
On Sun, Mar 27, 2011 at 6:07 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/27/2011 10:52 AM, Jim Jagielski wrote: With APR 1.4.3 and APU 1.3.11 coming soonish, as well as the number of changes in httpd-land itself, I think I will start planning the next beta release (2.3.12-beta). I also think the general consensus is to bundle mod_fcgid with 2.4 as well, and might as well do this now. The question is do we just bundle it with trunk or do we actually move/merge the repo into trunk. My pref would be the latter... move/merge doesn't address our 2.2 users. I'm happy to make the appropriate svn cp's (not all files are needed), and will attack this as soon as my commitments to apr project are done. I know Jeff is equally familiar and could do this if he has free cycles, but I'm not offering him up :) That's his call. I might think about that before long. :) As the next beta is presumably waiting for apr 1.4.next/apr-util 1.3.next I'm guessing we have some more days. What I really want is some time to think only about fcgid and some in-progress work there and what is important+achievable before 2.4 GA.
new ProxyPass/ProxyPassReverse feature for 2.4??
Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? It seems bogus to me that we still require such things... Of course, we can't get rid of it completely, to handle such cases as: ProxyPass / ajp://localhost:8009/jsp/ ProxyPassReverse / http://www.example.com/jsp/ but shouldn't we automagically handle the common case??
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On Mon, 28 Mar 2011 15:08:13 -0400 Jim Jagielski j...@jagunet.com wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? The thought had crossed my mind, not least with reference to mod_proxy_html. It seems bogus to me that we still require such things... Of course, we can't get rid of it completely, to handle such cases as: ProxyPass / ajp://localhost:8009/jsp/ ProxyPassReverse / http://www.example.com/jsp/ Exactly, there are complexities. but shouldn't we automagically handle the common case?? It's a nice idea, that would be nicer still if it would also handle the related cookie directives. This kind-of feels like a macro on top of the existing directives. How about preserving the existing directives, but offering something new and higher level? Gateway / ajp://localhost:8009/jsp/ (or Gateway / balancer://foo/) # ProxyPass flags # any non-inferred ProxyPassReverse/etc directives # Other Location stuff such as authnz, filters, etc /Gateway -- Nick Kew Available for work, contract or permanent. http://www.webthing.com/~nick/cv.html
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 3/28/2011 2:08 PM, Jim Jagielski wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? No. The right logic is to not use the ProxyPassReverse mapping mechanics at all, they are horribly inefficient. Note the prev / replace pair in the request during the initial ProxyPass match, and on the response side, instead of/in addition to looking in the ProxyPassReverse map, perform this one and only one remapping based on the noted replacement. Perhaps ProxyPass needs a flag to say 'no, don't reverse this', but I sort of doubt it.
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On Mar 28, 2011, at 3:46 PM, William A. Rowe Jr. wrote: On 3/28/2011 2:08 PM, Jim Jagielski wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? No. The right logic is to not use the ProxyPassReverse mapping mechanics at all, they are horribly inefficient. Note the prev / replace pair in the request during the initial ProxyPass match, and on the response side, instead of/in addition to looking in the ProxyPassReverse map, perform this one and only one remapping based on the noted replacement. Perhaps ProxyPass needs a flag to say 'no, don't reverse this', but I sort of doubt it. Huh? So how do you propose taking care of handling the Location redirects??
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 3/28/2011 2:53 PM, Jim Jagielski wrote: On Mar 28, 2011, at 3:46 PM, William A. Rowe Jr. wrote: On 3/28/2011 2:08 PM, Jim Jagielski wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? No. The right logic is to not use the ProxyPassReverse mapping mechanics at all, they are horribly inefficient. Note the prev / replace pair in the request during the initial ProxyPass match, and on the response side, instead of/in addition to looking in the ProxyPassReverse map, perform this one and only one remapping based on the noted replacement. Perhaps ProxyPass needs a flag to say 'no, don't reverse this', but I sort of doubt it. Huh? So how do you propose taking care of handling the Location redirects?? That's why I suggest 'in addition to'. Some things may not be possible. mod_rewrite [P]'s likely need ProxyPassReverse to stick around a while, too. The question comes down to, is there a reason not to try to reverse map back the original request by the match within the ProxyPass lookups, if it was found? Where we know the origin url and target proxypass url (including that of the one specific balancer member), we are all set to note this pair and perform the reverse translation later. No need to search through a huge pattern table.
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On Mar 28, 2011, at 4:11 PM, William A. Rowe Jr. wrote: On 3/28/2011 2:53 PM, Jim Jagielski wrote: On Mar 28, 2011, at 3:46 PM, William A. Rowe Jr. wrote: On 3/28/2011 2:08 PM, Jim Jagielski wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? No. The right logic is to not use the ProxyPassReverse mapping mechanics at all, they are horribly inefficient. Note the prev / replace pair in the request during the initial ProxyPass match, and on the response side, instead of/in addition to looking in the ProxyPassReverse map, perform this one and only one remapping based on the noted replacement. Perhaps ProxyPass needs a flag to say 'no, don't reverse this', but I sort of doubt it. Huh? So how do you propose taking care of handling the Location redirects?? That's why I suggest 'in addition to'. Some things may not be possible. mod_rewrite [P]'s likely need ProxyPassReverse to stick around a while, too. The question comes down to, is there a reason not to try to reverse map back the original request by the match within the ProxyPass lookups, if it was found? Where we know the origin url and target proxypass url (including that of the one specific balancer member), we are all set to note this pair and perform the reverse translation later. No need to search through a huge pattern table. I *think* we're talking the same thing here... you seem to be focusing on how ProxyPassReverse is currently implemented, which is horribly slow, but but making ProxyPass automatically handle the default PPR case means we don't need to use that implementation.
ldap unreleasable
/* LDAP cache state information */
typedef struct util_ldap_state_t {
...
int connectionPoolTTL;
} util_ldap_state_t;
I'm continue to grow more worried that the state of ldap in httpd
and in apr enjoys very little granularity, oversight, or quality...
1. Hungarian? Forgot to eat breakfast that day? Out of bounds
per httpd style rules.
2. int? Really? This is assigned an apr_interval_time_t in its
config code.
Please review and fix the style violations, and ensure that timeouts
are doing what they were meant to do.
Re: ldap unreleasable
On Mon, Mar 28, 2011 at 6:13 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
/* LDAP cache state information */
typedef struct util_ldap_state_t {
...
int connectionPoolTTL;
} util_ldap_state_t;
I'm continue to grow more worried that the state of ldap in httpd
and in apr enjoys very little granularity, oversight, or quality...
1. Hungarian? Forgot to eat breakfast that day? Out of bounds
per httpd style rules.
2. int? Really? This is assigned an apr_interval_time_t in its
config code.
Please review and fix the style violations, and ensure that timeouts
are doing what they were meant to do.
Thanks for the review, blockers above in r1086432 (and bugfix in r1086433)
--
Eric Covener
cove...@gmail.com
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 3/28/2011 2:08 PM, Jim Jagielski wrote: Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? It seems bogus to me that we still require such things... Of course, we can't get rid of it completely, to handle such cases as: ProxyPass / ajp://localhost:8009/jsp/ ProxyPassReverse / http://www.example.com/jsp/ but shouldn't we automagically handle the common case?? Big +1 here. -- -- Daniel Ruggeri
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 29 Mar 2011, at 12:10 AM, Jim Jagielski wrote: I *think* we're talking the same thing here... you seem to be focusing on how ProxyPassReverse is currently implemented, which is horribly slow, but but making ProxyPass automatically handle the default PPR case means we don't need to use that implementation. What I did to handle the slow list case for both ProxyPass and CacheEnable (which was modeled on ProxyPass originally) was to teach the directive to have a once-only per-directory value, which takes precedence if set, but reverts to the slow list if unset. It may be worth doing the same with ProxyPassReverse? And if nothing matches, we can default to sensible behaviour (ie automated ProxyPassReverse). Does this make sense? Regards, Graham --
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 3/28/2011 6:03 PM, Graham Leggett wrote: On 29 Mar 2011, at 12:10 AM, Jim Jagielski wrote: I *think* we're talking the same thing here... you seem to be focusing on how ProxyPassReverse is currently implemented, which is horribly slow, but but making ProxyPass automatically handle the default PPR case means we don't need to use that implementation. What I did to handle the slow list case for both ProxyPass and CacheEnable (which was modeled on ProxyPass originally) was to teach the directive to have a once-only per-directory value, which takes precedence if set, but reverts to the slow list if unset. My suggestion isn't per-dir. It's a r-notes which is even more efficient.
Re: ldap unreleasable
On 29 Mar 2011, at 12:13 AM, William A. Rowe Jr. wrote:
/* LDAP cache state information */
typedef struct util_ldap_state_t {
...
int connectionPoolTTL;
} util_ldap_state_t;
I'm continue to grow more worried that the state of ldap in httpd
and in apr enjoys very little granularity, oversight, or quality...
1. Hungarian? Forgot to eat breakfast that day? Out of bounds
per httpd style rules.
2. int? Really? This is assigned an apr_interval_time_t in its
config code.
Please review and fix the style violations, and ensure that timeouts
are doing what they were meant to do.
Please be aware that the person who donated this code to us isn't an
ASF person, and donated the code in good faith. If it doesn't fit our
style guide, we should fix it, and show respect for their original
contribution.
Looks like mod_ssl needs some similar cleanup, there are still style
violations in there, not limited to the examples below. Now would be a
good time to overhaul style.
typedef struct {
...
} SSLConnRec;
typedef struct {
pid_t pid;
apr_pool_t *pPool;
BOOLbFixed;
apr_global_mutex_t *pMutex;
apr_array_header_t *aRandSeed;
apr_hash_t *tVHostKeys;
void *pTmpKeys[SSL_TMP_KEY_MAX];
apr_hash_t *tPublicCert;
apr_hash_t *tPrivateKey;
const char *szCryptoDevice;
struct {
void *pV1, *pV2, *pV3, *pV4, *pV5, *pV6, *pV7, *pV8, *pV9,
*pV10;
} rCtx;
} SSLModConfigRec;
Regards,
Graham
--
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 29 Mar 2011, at 1:08 AM, William A. Rowe Jr. wrote: My suggestion isn't per-dir. It's a r-notes which is even more efficient. One further thing - it would need to work sanely from within a LocationMatch too. Regards, Graham --
Re: ldap unreleasable
On 3/28/2011 6:18 PM, Graham Leggett wrote: Looks like mod_ssl needs some similar cleanup, there are still style violations in there, not limited to the examples below. Now would be a good time to overhaul style. Agreed; it's much harder (and less justifiable) to make these sorts of changes mid-maintenance after a 2.4.0 tag, especially since they are harder to follow/ignore than whitespace changes. +1 to whomever wants to do the very significant work of un-Hungarianizing mod_ssl at this juncture. The reason I never did this is because SSL uses some Hungarian notation itself, and at the interface boundary it's less worrying. But you are pointing out httpd'isms and apr'isms which shouldn't have been expressed that way. FWIW I come from that background myself :) But my examples in httpd are limited to the places in mod_isapi where we intersect with Win32 constructs, so it actually makes the code more legible to know 'that data' is over on the isapi side of the world, and this other data is rooted in and managed by httpd.
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 3/28/2011 6:19 PM, Graham Leggett wrote: On 29 Mar 2011, at 1:08 AM, William A. Rowe Jr. wrote: My suggestion isn't per-dir. It's a r-notes which is even more efficient. One further thing - it would need to work sanely from within a LocationMatch too. Regex's aren't generally reversible (differential?). With a clever set of grouping operations, perhaps you could get back there, but I doubt it.
Re: new ProxyPass/ProxyPassReverse feature for 2.4??
On 3/28/2011 6:31 PM, William A. Rowe Jr. wrote: On 3/28/2011 6:19 PM, Graham Leggett wrote: On 29 Mar 2011, at 1:08 AM, William A. Rowe Jr. wrote: My suggestion isn't per-dir. It's a r-notes which is even more efficient. One further thing - it would need to work sanely from within a LocationMatch too. Regex's aren't generally reversible (differential?). With a clever set of grouping operations, perhaps you could get back there, but I doubt it. And it's the same reason that RewriteMatch [P] operations can't be reflected back to an origin path in any sane way. Our classic ProxyPassReverse isn't going anywhere soon :) The interesting question is, once we can determine origin/target uri paths, which gets applied first? The ProxyPassReverse transformations, or the direct ProxyPass reversal?
warnings sent to /dev/null during build?
I'm building with libtool2 on Ubuntu maverick, with --enable-maintainer-mode, but even though we're setup for lots of gcc warnings they're getting sent to /dev/null! I'm pretty sure I had seen (non-fatal) warnings in the past -- is this normal? make[4]: Entering directory `/home/covener/SRC/httpd-trunk/modules/ldap' /home/covener/SRC/httpd-trunk/srclib/apr/libtool --mode=compile ... -c util_ldap.c touch util_ldap.slo libtool: compile: gcc -std=gnu99 -g -Wall ... -c util_ldap.c -fPIC -DPIC -o .libs/util_ldap.o libtool: compile: gcc -std=gnu99 -g -Wall ... -c util_ldap.c -fPIC -DPIC -o util_ldap.o /dev/null 21 ^^^ (non-snipped: http://people.apache.org/~covener/warnings_dev_null.txt)
Re: warnings sent to /dev/null during build?
On Mon, Mar 28, 2011 at 9:13 PM, Eric Covener cove...@gmail.com wrote: I'm building with libtool2 on Ubuntu maverick, with --enable-maintainer-mode, but even though we're setup for lots of gcc warnings they're getting sent to /dev/null! I was confused about the repetition I pasted. FAQ says: Notice that the second run of GCC has its output discarded. This is done so that compiler warnings aren't annoyingly duplicated. If you need to see both sets of warnings (you might have conditional code inside ‘#ifdef PIC’ for example), you can turn off suppression with the -no-suppress option to libtool's compile mode: Which I am guessing is somehow conflicting with our building of shared modules (first one is a no-op?)
Re: warnings sent to /dev/null during build?
just my confusion adding -Wconversion to make invocation incorrectly, but will look at getting -Wconversion in maintainer mode when available.
Re: warnings sent to /dev/null during build?
On 3/28/2011 8:13 PM, Eric Covener wrote: I'm building with libtool2 on Ubuntu maverick, with --enable-maintainer-mode, but even though we're setup for lots of gcc warnings they're getting sent to /dev/null! I'm pretty sure I had seen (non-fatal) warnings in the past -- is this normal? make[4]: Entering directory `/home/covener/SRC/httpd-trunk/modules/ldap' /home/covener/SRC/httpd-trunk/srclib/apr/libtool --mode=compile ... -c util_ldap.c touch util_ldap.slo libtool: compile: gcc -std=gnu99 -g -Wall ... -c util_ldap.c -fPIC -DPIC -o .libs/util_ldap.o libtool: compile: gcc -std=gnu99 -g -Wall ... -c util_ldap.c -fPIC -DPIC -o util_ldap.o /dev/null 21 ^^^ If you tweak apr to drop the --silent option, what happens?
