Re: the wheel of httpd-dev life is surely slowing down, solutions please
At 12:47 PM 11/13/2003, [EMAIL PROTECTED] wrote: If you look at what has REALLY happened in the past 3 years ( yes... going back that far since it's now 4 or 5 years since 2.0 became a real blib on the radar ) there's no question that there was this intense period of development and 'new' things were happening at a fast rate. Without a doubt this period of development was abnormally intense for any five year old open source project. Good point. As more and more developers got interested in getting 2.0 cranked out the (limited) resources all got eaten up in the 2.0 development cycle and 1.3 development virtually shut down. It was even 'officially' shut down long before 2.0 was ready ( 1.3 officially went into maintenance mode only ). That's an interesting point. Most of my early (independent) contributions, about 600 dev hours worth, were entirely focused on making 1.3 work under Win32. And you are dead on, some of my work was accepted, and on other points, I was asked hold on, that's a goal in 2.0. There was a little difference though, there really was very little 2.0 anything at that time for me to point my efforts at. So now you had lots of legacy developers ( albeit... lots of weekend-warriors, too, but WW's are the heartbeat of Open Source ) who knew 1.3 very well but were now totally put out to pasture. Nay, they were gone long before I started using/working with/hacking Apache in 2000. Even mod_ssl and OpenSSL were put to bed. The old guard had moved on, and few folks paid much attention to the bug queue. Those that did were overwhelmed by some requests that just wouldn't fit well into the architecture of 1.3. Not to mention that 1.3's core was a twisted mess of platform quirks. It still is, that's why it's orphaned. Hard on old timers, sure, but for newcomers the difference between reading 1.3 and 2.0 is night and day. Yes filters are difficult to grok, but the rest of the entire server is much more simple to follow. Perhaps some will be motivated to make filters, the most difficult 2.0 feature, a little easier to use or understand. Justin already made some progress on this front, and it continues to evolve. The 'other' not-so-dedicated-but-certainly-interested developers felt 'shut out' of the 2.0 development cycle because it was obvious a lot of it was taking place 'off line' and nothing was being documented so they couldn't really get a good handle on what was going on in order to make a contribution. Hehe, of all of your silly perceptions in this note, I'm picking up on this one for the benefit of newer list readers. In the bad old days of the 2.0 dev cycle, very little ever happened that wasn't tracked on the mailing list. Today, there is parallel activity on channels like #apr (of irc.freenode.net), and your comment reinforces the point that not all of that activity can be healthy for the wider community. Unless it is digested and explained to the readership of dev@ and in the maillist archives for posterity and future explanation. At one point one of the Covalent guys ( I believe it was that Randy Bloom fellow? ) was pretty much the ONLY person who had any idea how the new 'filtering' was even SUPPOSED to work. It was quite some time before he even finished thinking it through and it went through (too?) many re-works to even keep a good grasp on it. Hehe, this ties into my point in the prior paragraph. EVERYTHING on the filters was nailed down on the list. What happened? Two camps had two different end goals. They did not see eye to eye on the design. When it got to the point that there was no resolution to be found, I suggested that a face to face of everyone interested would be terrific. Note I was an independent, not paid for webserver apps but actually a database systems dude who liked playing with the web. And I was tired of waiting for the discussion to end (and sorta confused as were most observers.) About 20+ folks, five different firms, some independents, some by phone, sat down to watch Ryan and Greg duke out the design one bullet point at a time. It was amazing, wish that someone had a brought a camcorder :-) And what resulted was a design that satisfied *everyones* requirements. Details and skeletons were posted to the list in realtime by some observers. What do you call this? An impromptu mini-hackathon. And it worked to move forward on a very difficult-to-follow concept. My only real point here ( and the way all this relates to the current thread ) is that maybe it's time to acknowledge that what is happening now is what will always happen to a major development project if you let too many of your eggs go into the same 'corporate' basket. I'm gonna just close with this observation - Apache was always driven by two forces, academic and business. By ISPs who needed a stable platform. By independent coders who earned a living doing systems. By companies who needed a stable and trusted base platform. And Guess What? There is
Apache 2.0 Uptake thoughts
For those interested in the question of Apache 2.0 uptake, my favorite resource is http://www.securityspace.com/s_survey/data/index.html - where you get gobs of details. The upgrade/downgrade report helps identify if a release was a winner (mostly upgrading to, or through, that version) - or a loser (when you see some significant percentage fall back on earlier releases.) Drill down to Theft and Upgrades, choose Apache, then a specific release, e.g. 2.0.47. Scroll down to the version upgrade/downgrade list. Some of this is going to be random noise - multiple versions working in a distributed farm, pre-adoption testing, or difficulty reconfiguring the server (in the case of 1.3 - 2.0 transitions.) But notably, 29.4k sites upgraded to .47 in October, and 1k sites backed down. Good retention, it indicates that the 2.0.47 release solved problems. (191 moved forward to 2.0.48-dev, not a bad thing at all.) The server details is also fun, no matter if you are comparing products or very specific releases. Here's where it's interesting. IIS 6.0 has 1.28% of the servers out there, that's about 5 1/3% of all IIS servers deployed. This, with a version that rolls out-of-the-box with specific flavors of the Windows OS. About the same time as IIS 6, Apache 2.0 rolled out. Ignoring for a moment the 9.13% of Apache servers that don't reveal their version whatsoever, ang ignorning rounding errors, 3.57% of the servers out there use some 2.0 version of Apache, so that 6% of Apache servers (identifying themselves) run 2.0 as opposed to another version. Personally, I'm pleased by a 6% uptake in a software application that doesn't have to change till someone needs the new features, given that we continue to provide the security patches people need for their existing 1.3 infrastructure. Of course it will only grow higher if folks trust 2.0 and can get their problems solved, which the current dialog in [EMAIL PROTECTED] I hope will help address. Just statistics to ponder as we approach next week. See you all in Vegas! Bill
Re: the wheel of httpd-dev life is surely slowing down, solutions please
Although it's probably a little late to be responding to innuendo, the bare minimum points that need a response; At 12:36 AM 11/14/2003, [EMAIL PROTECTED] wrote: There was a lot going down 'offline' and things were just being 'announced' on the forum. That's the way development often happens. Pound on code for a week and present it when it's working. You are reading just a little too much cloak and dagger into things. What you neglected to mention was that this now-famous '303 - Second Street - San Francisco' in-person huddle that you are talking about took place at ( you guessed it ) Covalent Corporate headquarters. Yup - they hosted it, although had 1/2 the committers been in the same area on the east cost, our friends in Raleigh were happy to open their meeting room. How long after that meeting was it that they hired you? You were then ( still? ) in Nebraska, yes? I started consulting for them sometime after that meeting, when Ryan appealed for my help. I joined Covalent that following March. And nope, never NE, I've lived in Chicago most of my life, but for a few year sabbatical in upstate NY. Had never even met any Apache or Covalent folk in person till that meeting. I'm proud that I've been a contributor before Covalent reinsert text snipped for trollbait and will remain ( proud ) even if I find other opportunities at some point. /reinsert Funny wording. Do you mean you aren't proud to be a contributor now that you ARE at Covalent? Nope, I mean exactly that, I played with Apache for the heck of it and got alot out of the experience. It reassured me that C is not dead (another parallel discussion that's getting a little silly :-) And I'm equally proud to be part of Covalent, and proud of what Covalent employees have contributed to Apache, and the Apache 2.0 version. Bill And with that minimum response... ignore class=troll/
Re: the wheel of httpd-dev life is surely slowing down, solutions please
At 12:36 AM 11/14/2003, [EMAIL PROTECTED] wrote: 'Individual' attempts to contribute are getting IGNORED and the last few words of this message thread's subject line are just asking to hear from the powers that be what they intend to do about that ( solutions please ? ). Yes, I think that's the page everyone is on. How to solve this. ( and before you come back with the standard Are YOU willing to review patches, then? at least I'll be honest and say there's NO WAY right now or for the forseeable future. Unlike you... I am NOT paid to work on Apache and I just don't have the time. [...] Actually, I invest far more than 40 hours in my work and Apache time, and I know of many others (from other companies) that do likewise. But you just hit the nail on the head, NO WAY. Nobody suggested that the core committers must single-handedly review the wealth of patches that are offered on this list and added to bugzilla! How can we communicate to this list, bugzilla users and others, that all it takes is to vote on the patch (in bugzilla, or by posting to this list) that the proposed solution actually solves the problem, and didn't break anything else in the process?!? It works for me are the four sweetest words to read when any of us are spending a free hour looking for patches to consider and apply! Besides, I'm also about 100% sure you don't want me reviewing patches for Apache. Newcomers can go read some archived messages if they are curious about the history there. ) If the casual reader is wondering why Kevin is unfortunately not been welcomed with open arms, by all means do go back over those archives. Then again, one doesn't need to scroll back more than the past day or few. Forgive in advance, Kevin, if I now tune you out. Bill
Re: the wheel of httpd-dev life is surely slowing down, solutionsplease
At 01:45 PM 11/14/2003, Sander Striker wrote: On Thu, 2003-11-13 at 09:06, Jeff Trawick wrote: Aaron Bannert wrote: On Tue, Nov 11, 2003 at 09:55:24AM -0700, Brad Nicholes wrote: Just to point out the obvious fact that hopefully everybody can agree with and consider taking action on: More code review[er]s would be useful regardless of C-T-R vs. R-T-C. And whether or not you agree with the current order of Committing and Reviewing for the stable branch, helping out with reviews would result in fixes being merged into the stable branch much faster. Exactly. And may I also note that releases are way more likely not to be duds now we are using R-T-C on the stable branch? I have noticed a significant difference in effort it takes to release since we switched stable to R-T-C. ++1. When something must-be-fixed (such as building on the fd/handle inheritence fixes that were introduced for security, but introduced a few new bugs --- or the cgid issues) - a new release on 2.0 can be created with little hassle and is doesn't require each platform guru to 'weigh in' on new breakage on their platform. Nobody minds breakage in the process of improving the project. When httpd 2.0 and 2.1 were broken apart, we provided an autobaun for new development (2.1) that is as unstable as necessary to move forward, and maintained a nice, solid two lane bypass (2.0) that was reliable and ready to tag as a release with little pain and maximum return. Some may suggest this has slowed down development. I'd ask, do you have a patch that you didn't commit to 2.1 yet? If so, why not? I'd ask, if you are arguing about 2.0 - what's not moving forward 'fast enough' for your taste? Your patch is stuck, awaiting review? This last question I ask then is - if you are waiting for others to review your patch, how many patches did you provide review and feedback for last week? This must be a collaborative effort, if you aren't reviewing patches - please don't moan when there are too few folks to review your own patch. Bill
Re: ap_get_server_state()
The Enums look great, can we extend apr_query_mpm instead though?
Bill
At 05:17 PM 11/16/2003, Jeff Trawick wrote:
If Sander hadn't gone awol this wouldn't be so fubar. Any comments?
ap_server_state_t {
enum {AP_STARTING, AP_STARTED, AP_STOPPING} state;
enum {AP_FIRST_START, AP_SUBSEQUENT_START} start_type; /* if AP_STARTING */
enum {AP_GRACEFUL_STOP, AP_HARD_STOP} stop_type; /* if AP_STOPPING */
int init_hook_last_pass; /* boolean; if AP_STARTING;
gives hints to pre/post config hook
for those that need to do something
exactly once */
};
/* server maintains a global ap_server_state_t... ap_get_server_state()
* returns address of it */
void ap_get_server_state(ap_server_state_t **);
Re: consider reopening 1.3
At 07:32 PM 11/16/2003, Martin Kraemer wrote: ...only that tomorrow's apr might not be 100% compatible with today's. Think of mod_ssl's and mod_dav's problem (the apache_1.3 version). They must always add the apache_1.3 version number to their own version number to describe the API they require. I would not like a apache-1.3.30-mod_ssl-2.8-20-apr-1.0.14 kind of delivery scheme. Of course not. mod_ssl's legacy goes to apache's legacy of breaking compatibility early and often when it made things better/easier/simpler. Apache 2.0 and APR 0.9 (soon 1.0) have avoided that approach as best as possible (the poll API being the big exception.) If you need apache 2.0 you need apr 0.9. The API should be stable. If you need apache 2.2 you will need apr 1.0 (or 1.1 if changes happen to make 2.2 a possibility). And within a given point release, apache 2.2 or apr 1.1, nothing will be broken. That's the contract we are aiming for to avoid the very headache you describe above. Bill
Re: Apache + Windows
At 02:34 PM 11/18/2003, Bill Stoddard wrote: Peter J. Cranstone wrote: If I am not mistaken, I seem to recall that TransmitFile() is artifically limited to serving no more than 10 TCP connections on non server editions of Windows. I've not actually tried it myself. Not TCP connections. This limit comes into play through the authentication manager. There is a hardcoded limit of the number of users who can be simultaniously authenticated through the winnt login manager. mod_auth_ntlm/mod_auth_sspi etc can all be victims of this limit. Bill
[PATCH] NO_USE_SIGACTION - no use undecorated names
We need to axe or decorate the symbol NO_USE_SIGACTION in our ongoing effort to prevent namespace clashes. However, this turned out to be a nontrival problem. It doesn't appear that this option was ever a tunable APR option. We do have a flag APR_HAVE_SIGACTION which is tested and configured for, and the attached patch to the Apache MPMs presumes that this was the intent of APR_HAVE_SIGACTION. But it will enable all platforms to use the (likely untested) sigaction code in the various MPMs. If we are choosing on *Apache's* behalf to use (or not use) sigaction, then this flag, or it's newly renamed cousin, needs to be an apache conf variable and disappear altogether from APR. Comments please from those who know the sigaction code? If there are no comments, I'll commit the apr half tomorrow to prepare for the release of APR 1.0. Bill sigaction.patch Description: Binary data
Re: [PATCH] 1.3: Add %X as alias for %c in LogFormat
+1 for 1.3 - we made this change already for 2.0 when we encountered
the problem (as we ship mod_ssl in 2.0, but not in 1.3).
I found it interesting that you retained %c - I presume this means that
%c continues to work until mod_ssl replaces it's meaning?
Bill
At 02:16 PM 11/20/2003, you wrote:
This has been itching me for awhile... I don't like loosing
%c whenever mod_ssl is in the mix. This is basically a
feature (yes, I said it, a feature) from 2.0 that makes sense
in 1.3. The other logable items would be nice as
well (%C) but this is core, I think.
The other cruft is simply to put things in alphabetical order
(for the sole reason of making the comments and code easier
to read and match).
Index: src/modules/standard/mod_log_config.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_log_config.c,v
retrieving revision 1.90
diff -u -r1.90 mod_log_config.c
--- src/modules/standard/mod_log_config.c 3 Feb 2003 17:13:28 - 1.90
+++ src/modules/standard/mod_log_config.c 20 Nov 2003 20:11:37 -
@@ -118,9 +118,11 @@
* literal characters copied into the log files, and '%' directives as
* follows:
*
- * %...B: bytes sent, excluding HTTP headers.
+ * %...a: remote IP-address
+ * %...A: local IP-address
* %...b: bytes sent, excluding HTTP headers in CLF format, i.e. a '-'
* when no bytes where sent (rather than a '0'.
+ * %...B: bytes sent, excluding HTTP headers.
* %...c: Status of the connection.
* 'X' = connection aborted before the response completed.
* '+' = connection may be kept alive after the response is sent.
@@ -128,15 +130,16 @@
* %...{FOOBAR}e: The contents of the environment variable FOOBAR
* %...f: filename
* %...h: remote host
- * %...a: remote IP-address
- * %...A: local IP-address
+ * %...H: the request protocol
* %...{Foobar}i: The contents of Foobar: header line(s) in the request
* sent to the client.
* %...l: remote logname (from identd, if supplied)
+ * %...m: the request method
* %...{Foobar}n: The contents of note Foobar from another module.
* %...{Foobar}o: The contents of Foobar: header line(s) in the reply.
* %...p: the port the request was served to
* %...P: the process ID of the child that serviced the request.
+ * %...q: the query string prepended by ?, or empty if no query string
* %...r: first line of request
* %...s: status. For requests that got internally redirected, this
* is status of the *original* request --- %...s for the last.
@@ -148,9 +151,7 @@
* %...U: the URL path requested.
* %...v: the configured name of the server (i.e. which virtual host?)
* %...V: the server name according to the UseCanonicalName setting
- * %...m: the request method
- * %...H: the request protocol
- * %...q: the query string prepended by ?, or empty if no query string
+ * %...X: An alias for %..c (Status of the connection).
*
* The '...' can be nothing at all (e.g. %h %u %r %s %b), or it can
* indicate conditions for inclusion of the item (which will cause it
@@ -500,9 +501,6 @@
int want_orig_default;
} log_item_keys[] = {
-{
-'h', log_remote_host, 0
-},
{
'a', log_remote_address, 0
},
@@ -510,70 +508,76 @@
'A', log_local_address, 0
},
{
-'l', log_remote_logname, 0
+'b', clf_log_bytes_sent, 0
},
{
-'u', log_remote_user, 0
+'B', log_bytes_sent, 0
},
{
-'t', log_request_time, 0
+'c', log_connection_status, 0
},
{
-'T', log_request_duration, 1
+'e', log_env_var, 0
},
{
-'r', log_request_line, 1
+'f', log_request_file, 0
},
{
-'f', log_request_file, 0
+'h', log_remote_host, 0
},
{
-'U', log_request_uri, 1
+'H', log_request_protocol, 0
},
{
-'s', log_status, 1
+'i', log_header_in, 0
},
{
-'b', clf_log_bytes_sent, 0
+'l', log_remote_logname, 0
},
{
-'B', log_bytes_sent, 0
+'m', log_request_method, 0
},
{
-'i', log_header_in, 0
+'n', log_note, 0
},
{
'o', log_header_out, 0
},
{
-'n', log_note, 0
+'p', log_server_port, 0
},
{
-'e', log_env_var, 0
+'P', log_child_pid, 0
},
{
-'V', log_server_name, 0
+'q', log_request_query, 0
},
{
-'v', log_virtual_host, 0
+'r', log_request_line, 1
},
{
-'p', log_server_port, 0
+'s', log_status, 1
},
{
-'P', log_child_pid, 0
+'t', log_request_time, 0
},
{
-'H', log_request_protocol, 0
+'T', log_request_duration, 1
},
{
-'m', log_request_method, 0
+'u', log_remote_user, 0
},
Re: [PATCH] NO_USE_SIGACTION - no use undecorated names
At 09:00 PM 11/20/2003, Jeff Trawick wrote:
William A. Rowe, Jr. wrote:
We need to axe or decorate the symbol NO_USE_SIGACTION in our
ongoing effort to prevent namespace clashes.
sounds good
We do have a flag APR_HAVE_SIGACTION which is tested and
configured for, and the attached patch to the Apache MPMs presumes that this was the
intent of APR_HAVE_SIGACTION.
can you take a look at that patch, Bill? (hint, save to disk first, then edit :) )
ROFL :-)
But it will enable all platforms to use the (likely untested) sigaction
code in the various MPMs.
but we're using the sigaction code now... what platforms besides windows actually
have NO_USE_SIGACTION defined?
Bah - was looking at apr.h not apr.h.in. You are correct.
code in the various MPMs. If we are choosing on *Apache's* behalf
to use (or not use) sigaction, then this flag, or it's newly renamed
cousin, needs to be an apache conf variable and disappear altogether
from APR.
Comments please from those who know the sigaction code?
I think everybody will end up using the same exact code, but the preprocessor check
will be nicer.
Well here's the patch... enjoy
Bill Index: server/mpm_common.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm_common.c,v
retrieving revision 1.108
diff -u -r1.108 mpm_common.c
--- server/mpm_common.c 3 Sep 2003 19:27:09 - 1.108
+++ server/mpm_common.c 20 Nov 2003 17:57:55 -
@@ -953,7 +953,7 @@
apr_status_t ap_fatal_signal_setup(server_rec *s, apr_pool_t *in_pconf)
{
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
struct sigaction sa;
sigemptyset(sa.sa_mask);
@@ -986,7 +986,7 @@
ap_log_error(APLOG_MARK, APLOG_WARNING, errno, s, sigaction(SIGILL));
#endif
-#else /* NO_USE_SIGACTION */
+#else /* !APR_HAVE_SIGACTION */
apr_signal(SIGSEGV, sig_coredump);
#ifdef SIGBUS
@@ -1002,7 +1002,7 @@
apr_signal(SIGILL, sig_coredump);
#endif /* SIGILL */
-#endif /* NO_USE_SIGACTION */
+#endif /* !APR_HAVE_SIGACTION */
pconf = in_pconf;
parent_pid = my_pid = getpid();
Index: server/mpm/experimental/leader/leader.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/experimental/leader/leader.c,v
retrieving revision 1.32
diff -u -r1.32 leader.c
--- server/mpm/experimental/leader/leader.c 16 Nov 2003 01:51:27 - 1.32
+++ server/mpm/experimental/leader/leader.c 20 Nov 2003 17:57:56 -
@@ -535,7 +535,7 @@
static void set_signals(void)
{
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
struct sigaction sa;
#endif
@@ -543,7 +543,7 @@
ap_fatal_signal_setup(ap_server_conf, pconf);
}
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
sigemptyset(sa.sa_mask);
sa.sa_flags = 0;
Index: server/mpm/experimental/perchild/perchild.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/experimental/perchild/perchild.c,v
retrieving revision 1.140
diff -u -r1.140 perchild.c
--- server/mpm/experimental/perchild/perchild.c 3 Sep 2003 19:27:11 - 1.140
+++ server/mpm/experimental/perchild/perchild.c 20 Nov 2003 17:57:57 -
@@ -401,7 +401,7 @@
static void set_signals(void)
{
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
struct sigaction sa;
#endif
@@ -409,7 +409,7 @@
ap_fatal_signal_setup(ap_server_conf, pconf);
}
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
sigemptyset(sa.sa_mask);
sa.sa_flags = 0;
Index: server/mpm/experimental/threadpool/threadpool.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/experimental/threadpool/threadpool.c,v
retrieving revision 1.20
diff -u -r1.20 threadpool.c
--- server/mpm/experimental/threadpool/threadpool.c 5 Sep 2003 19:36:26 -
1.20
+++ server/mpm/experimental/threadpool/threadpool.c 20 Nov 2003 17:57:58 -
@@ -606,7 +606,7 @@
static void set_signals(void)
{
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
struct sigaction sa;
#endif
@@ -614,7 +614,7 @@
ap_fatal_signal_setup(ap_server_conf, pconf);
}
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
sigemptyset(sa.sa_mask);
sa.sa_flags = 0;
Index: server/mpm/prefork/prefork.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.282
diff -u -r1.282 prefork.c
--- server/mpm/prefork/prefork.c16 Nov 2003 23:03:18 - 1.282
+++ server/mpm/prefork/prefork.c20 Nov 2003 17:57:59 -
@@ -400,7 +400,7 @@
static void set_signals(void)
{
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
struct sigaction sa;
#endif
@@ -408,7 +408,7 @@
ap_fatal_signal_setup(ap_server_conf, pconf);
}
-#ifndef NO_USE_SIGACTION
+#if APR_HAVE_SIGACTION
sigemptyset
Re: Release Frequency and Testing
I hope the response does not diminish your enthusiasm... The [EMAIL PROTECTED] mailing list (you can join up with a mail to [EMAIL PROTECTED]) maintains the mod_specweb and the perl-framework websites. I believe that flood is seperate at this point. Please - subscribe and contribute! The discussions recently have proven that 1) users wish we did more, and 2) there is more to be done. But httpd is a voulenteer project, so without enough hands raised - we are truly limited in what we can accomplish :) Most discussions of the exact mechanics of the test suite occur on that list - it is less-than-intuitive how to add some sorts of tests, and those who participate on the list can lend a hand to newcomers. Finally, understand that most new tests are reactions to current bugs, so that a brand new regression of code that never 'merited' a test might not be caught. So the ONLY WAY TO PREVENT THIS is to please, please, PLEASE obtain the release candidates and use them in real situations and production load. Until more do so, and scream at regressions, there is ultimately nothing we can do to avoid the sort of problem you encountered. Bill At 09:13 PM 11/23/2003, Robert La Ferla wrote: What testing gets performed prior to an official httpd 2.x release? I think whatever test suite is used, needs some updating to include configurations that utilize more features like user tracking, caching and multi-views. The last release (2.0.48) crashes on startup for my configuration which includes those features. I will submit a bug report later. However, I have seen some previous releases that had other crash bugs on startup as well. 2.0.48 was supposed to be a bug fix release but some other bugs were introduced. If the frequency of the 2.x releases was greater (shorter time between releases), it wouldn't be as a big of a problem. I have noticed that 2.x releases seem to take much longer than ones in the 1.x days. I guess what I am saying here is that I hope there can be some discussion about the frequency of releases (making a conscious effort to make them more frequent) as well as a review of what testing gets done prior to a release.
Re: Where is mod_access??
At 01:53 PM 11/26/2003, Christopher Jastram wrote: Okay, I'm really feeling stupid here. Where in the world is mod_access? httpd can't run because it chokes on the Order directive, which comes from mod_access. So where is it? I'm working on a clean (I hope) checkout of httpd-2.1 (cvs co httpd-2.1 httpd-2.0). I can't find mod_access.c anywhere, and it's driving me *crazy*...! Sorry, you may feel more comfortable checking out -r APACHE_2_0_BRANCH, since 2.1 restructures an number of modules. See the docs/manual/ within the 2.1 current development branch to get a slightly better handle on this. The mod_ssl problem you point out is a broken build - shmht was completed yanked (today) in favor of shmcb - so if you care to submit a quick patch to remove those references causing you grief, that would be terrific. Bill
Re: Where is mod_access??
At 02:51 PM 11/26/2003, Christopher Jastram wrote: I checked nagoya, there doesn't seem to be any way to submit bug reports (and patches) for httpd2.1. Do I submit it under 2.0 or post to the list? I've reclassed HEAD as 2.0-HEAD (since we can't know) and added a new category 2.1-HEAD. Hope that helps. Bill
Re: new IfThreaded directive (was Re: [patch] adding mpm info to httpd -V)
At 02:10 PM 12/3/2003, Geoffrey Young wrote: IfThreaded MaxThreadsPerChild 5 /IfThreaded This rubs me the wrong way FWIW. oops, sorry :) I don't care for that container either... but even horrible new ideas are always good when then generate more ideas :) If somebody really wants to do this they could use IfDefine; though it would be easier if the core pre-defined some symbol for use in IfDefine, it is doable as-is. sure. the only reason I didn't go that way was that the docs seem to say that IfDefine only applies to -D command-line parameters - I wasn't familiar enough with the directives to see if there were other, internal -D flags that were also used. Actually, such defines might need to be a little more dynamic, but either IfDefine AP_MPM_THREADED would be good, or if we absolutely needed too, we could add IfFeature FOO where features could be registered, by the core or by a loaded module. Individual IfFoo blocks would pollute the command table significantly, slowing down config parsing by a corresponding amount. Bill
Re: [PATCH] catching malformed container directives
At 09:36 AM 12/9/2003, Geoffrey Young wrote: André Malo wrote: I'd like to keep IfDefine possible. Simply because it's a very efficient way to comment a whole part out (reliably, since one cannot specify an empty -D argument). And it's in use out there. ok, here is a new patch that excludes IfDefine . Now you have me thinking. For Apache 2.1 (perhaps 2.0) I'd like to see that particular nonsense go away. I sympathize with André's observation that it's useful, but what he wants to do can be accomplished with IfDefine NEVER DangerousDirective /IfDefine which serves the same purpose, but it much more legible. You point out that containers that expect args (e.g. not Perl blocks) can be very difficult to debug in any sort of dynamic (mod_macro) sort of config environment. But also consider that many conf rewriting tools could probably crack under the strain of parsing such IfFoo containers, if they specify no argument. On the balance, for 2.1 forward we should disallow IfDefine . It's a coin toss to me if we continue to accept them in 2.0 - so I'd argue the principle of least surprise. Disallow in 2.1, but continue to allow in 2.0 IfDefine . also included is a patch (that applies on top of the other one) that fixes broken Limit containers. currently Limit GET does not throw an error (note the missing final ''). That would be goodness! Bill
Re: cvs commit: httpd-2.0 CHANGES
At 12:37 PM 12/9/2003, Stas Bekman wrote: Does this look good? ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, mod_include: Options +Includes (or IncludesNoExec) - wasn't set, passing data unmodified); + wasn't set, passing data unmodified, removing myself); +ap_remove_output_filter(f); Admins have to read this message in their logs, not coders. What about this: mod_include: Options +Includes (or IncludesNoExec) wasn't set, include filter removed
Re: filtering huge request bodies (like 650MB files)
At 04:57 PM 12/10/2003, Cliff Woolley wrote: On Wed, 10 Dec 2003, Stas Bekman wrote: Obviously it's not how things work at the moment, as the memory is never freed (which could probably be dealt with), but the real problem is that no data will leave the server out before it was completely read in. Yes, that would be the real problem. So somewhere there is a filter (or maybe the proxy itself) buffering the entire data stream before sending it. That is a bug. It's NOT the proxy - I've been through it many times - and AFAICT we have a simple leak in that we don't reuse the individual pool buckets, so memory creeps up over time. It isn't even the end of the world, until someone at apachecon pointed out continous HTML proxied streams (e.g. video) really gobble memory, even at 8kb/min+ this isn't acceptable. So it's not the proxy or the core output filter. The bug lies in the Filter itself. Is it Chrises' own filter or one of ours? whichever it is, it would be nice to get this fixed. This is why we aught to not flip subject headers, Stas, I'm really too short on time to go fumbling for the original posts. Need to know which filters are inserted, and therefore possibly suspect. Bill
Re: [PATCH] Create plog pool before pconf
So you propose an inversion here? Won't that break as many modules making the (currently) correct assumptions, w.r.t. config data? Logs are created *from* values in the configuration, ergo they should go away *before* the values that created them are also destroyed. E.g., if my module creates a log file, and points at the name of that log, then the name of that log cannot become invalid before that log file is destroyed and cleared. Bill At 11:53 PM 12/10/2003, Bill Stoddard wrote: Check out this PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20462 plog is created after pconf which means that plog will be cleaned up before pconf during destroy_and_exit_process() called during shutdown. It is not uncommon for modules to register cleanups against pconf and log messages during these cleanups. Since plog has already been cleaned up, nasty things can happen. But... some of the nastiness reported in the PR may come from improper use of cleanups. If a single module registers multiple cleanups against pconf and those cleanups have dependencies on each other, well, you reap what you sow. Comments b4 I commit this to 2.1? Index: include/httpd.h === RCS file: /home/cvs/httpd-2.0/include/httpd.h,v retrieving revision 1.191.2.7 diff -u -r1.191.2.7 httpd.h --- include/httpd.h 24 Nov 2003 16:07:52 - 1.191.2.7 +++ include/httpd.h 11 Dec 2003 05:40:12 - @@ -704,6 +704,8 @@ const char * const *argv; /** The program name used to execute the program */ const char *short_name; +/** Logging pool. Cleared after each config read */ +apr_pool_t *plog; }; /** A structure that represents the current request */ Index: server/main.c === RCS file: /home/cvs/httpd-2.0/server/main.c,v retrieving revision 1.140.2.3 diff -u -r1.140.2.3 main.c --- server/main.c 27 Feb 2003 12:09:44 - 1.140.2.3 +++ server/main.c 11 Dec 2003 05:40:14 - @@ -276,6 +276,12 @@ process = apr_palloc(cntx, sizeof(process_rec)); process-pool = cntx; +/* The plog pool needs to hang around until the very end because + * modules may be logging messages in cleanups registered against + * pconf. + */ +apr_pool_create(process-plog, process-pool); +apr_pool_tag(process-plog, plog); apr_pool_create(process-pconf, process-pool); apr_pool_tag(process-pconf, pconf); @@ -428,6 +434,8 @@ process = create_process(argc, argv); pglobal = process-pool; pconf = process-pconf; +plog = process-plog; + ap_server_argv0 = process-short_name; #if APR_CHARSET_EBCDIC @@ -556,8 +564,7 @@ usage(process); } -apr_pool_create(plog, pglobal); -apr_pool_tag(plog, plog); + apr_pool_create(ptemp, pconf); apr_pool_tag(ptemp, ptemp);
Re: filtering huge request bodies (like 650MB files)
At 07:01 PM 12/10/2003, Bill Stoddard wrote: Aaron Bannert wrote: [slightly off-topic] Actually, I believe that mod_cgi and mod_cgid are currently broken WRT the CGI spec. The spec says that a CGI may read as much of an incoming request body as it wishes and may return data as soon as it wishes (all AIUI). I agree with your reading, it's the first bug report I ever filed on Apache. That means that right now if you send a big body to a CGI script that does not read the request body (which is perfectly valid according to the CGI script) then mod_cgi[d] will deadlock trying to write the rest of the body to the script. The best way to fix this would be to support a poll()-like multiplexing I/O scheme where data could be written do and read from the CGI process at the same time. Unfortunately, that's not currently supported by the Apache filter code. -aaron Interesting. Then Apache 1.3 is broken too. I believe Jeff posted a patch not too long ago to enable full duplex interface between Apache and CGI scripts. Unfortunately they are entirely unrelated. The 1.3 patch would be terrific, since on Win32 especially the pipe buffers were pretty small (until I increased them at least to 64k inbound/outbound.) But the 2.0 architecture is entirely different. We need a poll but it's not entirely obvious where to put one... One suggestion raised in a poll bucket: when a connection level filter cannot read anything more, it passed back a bucket containing a poll descriptor as metadata. Each filter passes this metadata bucket back up. Some filters like mod_ssl would move it from the connection brigade to the data brigade. When a module like mod_cgi saw the last apr_brigade_read, it could then multiplex what it wants to do with more data. Even with things like a charset conversion filter containing an incomplete sequence, or mod_ssl with some data but an incomplete packet, the module could continue to do 'something else' until that poll descriptor was signalled, then call back down the filter chain to read more data. Now poll buckets are a simple solution to read, but they don't work at all for write. mod_cgi[d] simply passes the pipe bucket out the filter chain and that operation is always blocking. The only valid result under today's filter design is sent, or could not send [fatal]. The first filter that cares reads from the cgi pipe, and transforms or writes that data. At that point we are deep in the output filter chain. The only sane solution I can think of would be a hybrid. On the read from client/write to pipe side, we implement a poll bucket. On the read from pipe side, we have to actually buffer the data instead of passing the pipe bucket down the filter chain. So we are polling on several events; CGI stdin pipe ready-to-write? \yes - write to the pipe, and also start polling again; Network (pipe bucket) ready to read? \yes - Read again (nonblock) from the input filters CGI stdout pipe data-to-read? \yes - read the available data (nonblock), and pass the brigade out This ignores if the network is ready to write because we just won't *do* anything till the CGI results have been written out. This also ignores a filter like mod_ext_filter. That filter implies that our poll buckets must allow for a collection of sockets/pipes to poll on. Two things can happen within the mod_ext_filter_in, either it's blocked for more data or it is truly taking it's time computing some results. We just don't (can't) know the answer to that puzzle from inside Apache. So consider mod_ext_filter_in. Let's presume there are three things that can trigger more labor in our hypothetical input filter... * it needs more input to continue. Solution: poll the network. * it is churning away at it's data. Solution: poll the ext filter's stdout pipe and the most complex case: * it is churning away, but the ext filter's stdin pipe is *full* still! Even with more network data, we have to ignore the fact that we have more data to give to the ext filter till it either empties the stdin pipe or has more stdout pipe results for us to process. Solution: the mod_ext_filter_in looks at the full stdin pipe and declines to read more from the network. It sets aside the current network input and does *not* return the network poll bucket, but instead passes it's own poll bucket of *both* the stdin and stdout ext filter pipes. Imagine a chain of such things - we really define the problem in terms of a set of filters that would trigger another nonblocking attempt to get the input chain moving again. So that's the input side - now to consider the output side. We can make one assumption here for the sake of the handler - we don't need the handler to do *anything* more until we can shoot it's cumulative results to the network. mod_ext_filter has the same stdin/stdout blocking problems of mod_cgi, so let's consider that complex filter case. If mod_ext_filter sees that the
Re: filtering huge request bodies (like 650MB files)
I've been thinking the same thing driving around this evening... One major goal of httpd-3.0 is *finally* arriving at something that starts looking async. We've kicked it around some time, but perhaps it's time to start looking at the async poll implementation, to get some idea of how we can 'poll' on multiple sorts of events. The one thing that is clear to me, pre-1.0: win32 needs to be able to poll pipes and sockets, *even* if it means a really lame 100ms timeout (perhaps configurable) on the socket poll to look sideways at the pipe info. There is no way to solve any of these problems without clearing that first hurdle. But you brought up a great point - what about some notification signals? How do we extend 'poll'. It sure looks like we need something more clever than a wrapper around posix poll/select. Bill At 02:52 PM 12/11/2003, Aaron Bannert wrote: On Thu, Dec 11, 2003 at 01:50:46PM -0600, William A. Rowe, Jr. wrote: But the 2.0 architecture is entirely different. We need a poll but it's not entirely obvious where to put one... One suggestion raised in a poll bucket: when a connection level filter cannot read anything more, it passed back a bucket containing a poll descriptor as metadata. Each filter passes this metadata bucket back up. Some filters like mod_ssl would move it from the connection brigade to the data brigade. At one level we'll have to fit whatever I/O multiplexer we come up with in the filters. I'm going to stay out of that discussion. At a lower level, ignoring filters for a moment, we still need a way for applications to be able to multiplex I/O between different I/O types: pipes, files, sockets, IPC, etc... I think this is the root of the problem (and something we should probably move over to the [EMAIL PROTECTED] list, and also something we might want to take up after APR 1.0 is released). -aaron
Re: new ETag supression/weakening API
Just a quick tangent on weak ETags let's say I have a transform to convert (charset-any) into utf-8 format... and based on a browser string, conditionally insert that filter. It's a straightforward (predictable) transform so that it retains any strong ETag, but it isn't the identity. Wouldn't it make more sense to concat a suffix onto the existing ETag? Bill
Re: cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c
At 03:57 PM 12/15/2003, Bill Stoddard wrote: [EMAIL PROTECTED] wrote: martin 2003/12/15 06:24:31 Revision ChangesPath 1.67 +70 -0 httpd-2.0/modules/experimental/mod_charset_lite.c +#if #system(bs2000) This syntax causes a compile failure on Windows. Of course - it is invalid C and C++ grammer. Too bad the cpp coders on that platform didn't review against the bnn. Bill
UseCanonicalName Off *surprise*
In both Apache 1.3 and 2.0 the UseCanonicalName doesn't work quite as it's
documented. The question would be, do we fix it or document it...
When requesting a document that results in a redirection (directory not
decorated by a trailing backslash, etc) the redirected server name doesn't
actually conform to the Host header provided by the client...
UseCanonicalName On
-or-
UseCanonicalName Off, but the Host: header was missing (e.g. HTTP/1.0)
In 1.3 - the host's {ServerName}:{Port} is returned.
In 2.0 - the host {Servername} is returned (must include port suffix).
there were no surprises there.
UseCanonicalName Off, Host: header provided (HTTP/1.1)
The host name header *excluding the host header port suffix * of the request
is concatenated to httpd 1.3's Port directive setting or the real port number
in httpd 2.0.
Now this might appear to be a moot issue, but if a proxy that doesn't mangling
headers bounces requests from port 80 to another server's port 8080 attempting
to impersonate the front end proxy, everything should work, in theory, with
UseCanonicalName Off. As it turns out, UseCanonicalName must be turned
on to avoid the port :8080 suffix from being appended to the redirects.
Host headers (from my usual clients) do appear in the form
Host: localhost:8080
when the request http://localhost:8080/ is sent. UseCanonicalName Off docs
state outright that we use the Host: header provided by the client. The example
above shows that we do not. But if we correct the behavior, instead of the docs,
then perhaps users will commonly end up with broken configs.
So I'm wondering what the consensus is - fix the docs, or the behavior?
Bill
Re: UseCanonicalName Off *surprise*
At 11:16 AM 12/19/2003, Tony Finch wrote: On Fri, Dec 19, 2003 at 10:04:15AM -0600, William A. Rowe, Jr. wrote: UseCanonicalName Off, Host: header provided (HTTP/1.1) The host name header *excluding the host header port suffix * of the request is concatenated to httpd 1.3's Port directive setting or the real port number in httpd 2.0. The Port directive has some muddled ServerName/UseCanonicalName semantics which is what distinguishes it from the Listen directive. I think the behaviour you describe is intended. Now this might appear to be a moot issue, but if a proxy that doesn't mangling headers bounces requests from port 80 to another server's port 8080 attempting to impersonate the front end proxy, everything should work, in theory, with UseCanonicalName Off. As it turns out, UseCanonicalName must be turned on to avoid the port :8080 suffix from being appended to the redirects. In this situation you should be using Listen rather than Port. Is 2.0 different? Let me be clear (on the 1.3 side)... one expects that given; UseCanonicalName Off Listen 8080 Port 80 an inbound request with a Host header of foo:80 would respond with the redirection http://foo:80/ It does not. The Listen port again applies until you turn UseCanonicalName On. Bill
Re: why open_logs/post_config hooks are run only for the main server?
At 03:36 AM 12/21/2003, Stas Bekman wrote: We have users who want to run different post_config hooks for different vhosts. Any chance httpd-2.0 can be changed to run the open_logs/post_config (or at least post_config) hooks for each vhost as well? Any reason for not doing that in first place? The issue would be that all modules presume these hooks are called once and only once, therefore they initialize global structures presuming this entry point won't be invoked again. It is almost worth a totally different hook entry point (before post_config) such as vhost_init which *would* be called per-vhost (starting from the main server config and working through the list.) I have several modules with the for (s=_server; s; s = s-next) paradigm that would be easier to read using such a hook. Although I'm generally against adding more cpu-intensive hook phases, this is an init-only hook so it's much easier to implement. We might also want to revisit the child_init hook, which is once/process. Some have asked for a per-thread init hook as well. Bill
Re: why open_logs/post_config hooks are run only for the main server?
Only question below is should this hook always run before or after the post
config hook? My gut says after post config.
At 11:19 AM 12/22/2003, Geoff wrote:
I had some spare time and thought I could help with the grunt work - my try
at a patch attached.
+for (s = server_conf; s; s = s-next) {
+if ( ap_run_vhost_init(pconf, plog, ptemp, s) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
+ 0, NULL, Unable to initialize virtual hosts\n);
+destroy_and_exit_process(process, 1);
+ }
+}
+
if ( ap_run_post_config(pconf, plog, ptemp, server_conf) != OK) {
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR, 0,
NULL, Configuration Failed\n);
@@ -692,6 +707,14 @@
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
0, NULL, Unable to open logs\n);
destroy_and_exit_process(process, 1);
+}
+
+for (s = server_conf; s; s = s-next) {
+if ( ap_run_vhost_init(pconf, plog, ptemp, s) != OK) {
+ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
+ 0, NULL, Unable to initialize virtual hosts\n);
+destroy_and_exit_process(process, 1);
+}
}
if (ap_run_post_config(pconf, plog, ptemp, server_conf) != OK) {
Re: why open_logs/post_config hooks are run only for the main server?
At 04:47 PM 12/22/2003, Stas Bekman wrote: I'm not sure this is a good idea to run it on the main host. If it was we could just as well run post_config for each vhost as well. No, you missed my earlier point. post_config is a run-once. host_init is the run-each you requested. The problem is that if that hook is configurable via a directive this directive will be inherited by all vhosts if defined in the main server (via the usual merge rules). And you end up running it for each vhost even if you didn't intend to. Stop... hooks aren't configured by directives as you imply. The directive is processed in some phase, but the hook runs against all. That's why we wondered why you couldn't loop it, although I had no objection to simply invoking this hook. As a matter of fact, you give me an idea I'll discuss at the end. As far as inheritance, hosts *should* inherit global settings unless the author goes to great pain to *document* and then provide such behavior. Intuitively folks presume inheritance within httpd.conf from global into each local conf. So if adding this hook at all, it should be invoked *only* on vhosts, and never on the main server [...] and then vhost_init is the right choice. No... the default server is still a server. But you make an interesting point, that certain percolation occurs in the post config. I suppose I would want that to happen before my handlers dealt with the per-vhost settings, and I would not want the changes I make to that global server to percolate any longer in the host_init phase. So running the post config, then the host init phases makes sense for that paradigm. If we invoke this hook for vhosts, it must be invoked on the main host. What the handlers do should be affected by the per-host directives, and not the other way around (handlers shouldn't be invoked because of per-host directives.) But let's imagine a scenario of dynamic vhosts, al la htaccess. It would actually be quite cool in one thread to create such a dynamic host (propagate from some given vhost for example.) This host init hook would still be run against the thread specific dynamic server record. We could get away with some really cool things that way :) Discuss ... Bill
Copyrights
At 06:32 AM 1/2/2004, you wrote: [EMAIL PROTECTED] wrote: update license to 2004. Why? Unless the file changes in 2004, the copyright doesn't. And, in any case, the earliest date applies, so it gets us nowhere. In fairness this has been Roy's practice, so let's not beat on Andre. Roy's logic is that this is a single work. If someone obtains a new tarball in 2004, all of the files will be marked with 2004, as some changes will have (undoubtedly) been made. Old tarballs of the combined work retain their old copyright dates. One copyright file isn't sufficient, each document must be copyrighted. The License itself will become a single, common document (not repeated in each file) as of the next ASL 2.0, if I understand right, and mentioned by reference in each individual file. But copyrights will be perpetually updated, each file is both separately copyrighted, as well as the combined work as a whole. I think that covers most comments on this thread. Bill
Re: what about 2.1.0 ?????
Günter, Just so that everyone is on the same page, 2.1.0 will be an -alpha. If and when we think we are about done with post 2.0 development, we will finally release a 2.1.x-beta. That will become the codebase (after an iteration or few) of the Apache 2.2 release. We are moving twords the tried-and-true release semantics of Perl, Linux kernels, and many other open source projects. Probably the number one issue would be APR 1.0-alpha acceptance. Once we set 1.0 in stone, there will be little distracting movement on that side of module development - so that Apache 2.1 third party module developers can really get their feet wet and demand the changes they need to see in 2.2 before we declare it golden and start this all over again :) Bill At 09:32 AM 1/8/2004, Günter Knauf wrote: Hi all, now we have already tagged for two times, tested, and nothing happened - no 2.1.0 release is out yet. What's about a new third try with a following release this time??? I really wish we could have 2.1 out so that the users get a version number they can refer to; that makes bug reports a lot easier I see on my hosts downloads that there is enough interest now for 2.1 PLEASE LET US PUT OUT A FIRST 2.1 RELEASE !!! thanks, Guenter.
Re: FD_SETSIZE comparison
Perhaps this is none of Apache's business, but should be a very specific
result from the various apr_poll setup functions that invoke select()?
Bill
At 08:53 AM 1/6/2004, Brian Akins wrote:
Call me stupid, put why in various places does Apache do things like this:
if (csd = FD_SETSIZE) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
new file descriptor %d is too large; you probably need
to rebuild Apache with a larger FD_SETSIZE
(currently %d),
csd, FD_SETSIZE);
apr_socket_close(sock);
return;
}
On linux, at least, FD_SETSIZE is fairly low (1024), yet the actually max file
descriptors can be much, much higher (we have thousands per process with squid).
Is this just not true elsewhere? Can someone explain?
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
Re: a dll section
??? Well, I think you are asking a docs question so I'm forwarding there. But this is nothing more than adding an appropriate LoadModule command, so it is likely documented there. Actually causing a loaded module (so, sl, dll or dylib) to actually do anything productive would be the documentation task of the module author. Depending on the module, other library dependencies may exist. So it's really not up to us to spell out the requirements and prerequisites for enabling any given third party module. That said, it's a paragraph and one line of illustration for the third party module author to document how to configure the module to work on Apache/Win32, along with all the rest of their documentation. Bill At 04:19 PM 1/5/2004, Saul, Sherwyn wrote: A section on how to install a .dll mod with out the corresponding .c file (ex. libphp4.dll) would be good. -sherwyn
Re: [Bug?] cvs commit: httpd-2.0/server core.c
Woha...
At 11:50 AM 1/8/2004, [EMAIL PROTECTED] wrote:
bnicholes2004/01/08 09:50:03
Modified:server core.c
Log:
If large file support is enabled allow the file to be split into AP_MAX_SENDFILE
sized buckets. Otherwise Apache will be unable to send files larger than 2 gig due
to signed 32-bit limitations.
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.254
retrieving revision 1.255
diff -u -r1.254 -r1.255
--- core.c1 Jan 2004 13:26:23 - 1.254
+++ core.c8 Jan 2004 17:50:03 - 1.255
@@ -3508,8 +3508,12 @@
}
bb = apr_brigade_create(r-pool, c-bucket_alloc);
-#if APR_HAS_SENDFILE APR_HAS_LARGE_FILES
+#if APR_HAS_LARGE_FILES
+#if APR_HAS_SENDFILE
if ((d-enable_sendfile != ENABLE_SENDFILE_OFF)
+#else
+if (
+#endif
(r-finfo.size AP_MAX_SENDFILE)) {
/* APR_HAS_LARGE_FILES issue; must split into mutiple buckets,
* no greater than MAX(apr_size_t), and more granular than that
Ok that is a messy one to grok but I think I got it...
Haven't you broken the EnableSendfile off directive if the user is trying to avoid
using sendfile on non-largefile builds?
E.g. if someone determines that their sendfile implementation is broken, will
the server still react properly to EnableSendfile off on linux or bsd?
Bill
Re: what about 2.1.0 ?????
At 04:51 PM 1/13/2004, Günter Knauf wrote: do you still expect massive changes with APR 1.0 ? I have the sense that folks want to see: * platform neutral apr_poll() that works on apr_file_t's as well, since so many daemons and other applications will require this. Non trivial - but we may just end up with a sleep(100 /*ms*/) poll test_files loop. Or we may have to use local socket pairs as the fallback daemon pipe mechanism. * completed documentation (Sander Temme has put in alot of effort at cleaning up the doxygen results, kudos!) I'm also feeling that running as-a-daemon should mostly be the effort of APR itself, so that the issues between normal daemons, Win32 services, and the odd unix dameon control environments are totally flattened out to be nearly platform-neutral. All that said, nothing should stop us from beginning 1.0-alphas (caviat: contents may settle during shipment) and getting some feedback on this front, too. But if these are rolled, I would really feel warmer and fuzzier with calling them APR 0.9.9, or something that will restrict them from ever being used with any app build for APR 1.0 release. Bill
Re: [Bug?] cvs commit: httpd-2.0/server core.c
At 07:05 PM 1/13/2004, Brad Nicholes wrote: I don't think so because the split into multiple bucket code was only enabled if both large_file and send_file was enabled. Which meant that on a non-large_file build the check for ENABLE_SENDFILE_OFF wasn't there anyway. If they have large_file support and don't have send_file (ie. NetWare), then the file must be split into multiple buckets or it doesn't work (32/64 bit type mismatches in the file size). If they have large_file support and send_file, then everything is as it was before. What about the case where they did have sendfile, but did not use large file support? [Did/Do] we attempt to test the EnableSendfile logic? If not, perhaps we should. There are other cases, e.g. some NFS volume strategies, where a raw kernel sendfile turns out to be fatal on some platforms. I'm not sure why a check for ENABLE_SENDFILE_OFF is here anyway. This code doesn't really have anything to do with whether or not sendfile is used. All it does is split a large file into multiple smaller buckets. If later down the line sendfile is used to actually send the file from multiple buckets, great. If not, that is fine also (as demonstrated by the fact that NetWare doesn't have sendfile() and it all works fine). Not arguing that breaking up huge responses is a bad thing :) However I'm somewhat confused why apr doesn't handle this gracefully. Bill
Re: httpd-2.1 segfaults at startup
Someone remarked to me yesterday that their out-of-box 2.0.48 tarball would
not build under SuSe...
I noticed a brand new change to the libdl detection logic that drops -ldl from the
linkage list on unix. Would you please check that the generated LDFLAGS
did or did not include the -ldl argument to libtool?
Bill
At 06:31 PM 1/13/2004, Art Haas wrote:
Hi.
I've been building and using what will be httpd-2.1 for months. Just
within the last week or two, my builds have all failed when I try to run
them. As others are certainly running the CVS head builds without
problems, I'm hoping for a bit of guidance to see if someone can suggest
a fix.
Here's the end of the 'strace' output - httpd has just started, and the
linker is pulling in all the libraries, when the following occurs:
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200X\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1270908, ...}) = 0
old_mmap(NULL, 1281292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401c
old_mmap(0x402ee000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12d000)
= 0x402ee000
old_mmap(0x402f7000, 7436, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x402f7000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x402f9000
set_thread_area({entry_number:-1 - 6, base_addr:0x402f9500, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0x40018000, 61414) = 0
set_tid_address(0x402f9548) = 12008
rt_sigaction(SIGRTMIN, {0x401b23e0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0) = 0x8095000
brk(0x80b6000) = 0x80b6000
brk(0) = 0x80b6000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
I'm running on Debian, with the latest libc6 package from unstable -
libc6-2.3.2.ds1-10. Apache was built with GCC-3.4 built from CVS on
January 9. The Apache build was configured as follows:
$ CPPFLAGS=-DNDEBUG CFLAGS=-O2 -march=pentium-mmx -std=gnu99 \
-finline-limit=10 /opt/build/httpd-2.1/configure \
--enable-mods-shared=all --enable-deflate --with-dbm=db42 \
--with-berkeley-db=/usr/local/BerkeleyDB.4.2
I've used these flags for months without problem, though the Berkeley
stuff is relatively new (I need 4.2 for use with Subversion). I'm
running the 2.6.1-rc3 kernel also.
Ideas for things to try? No one else is seeing this, correct?
Thanks in advance,
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
Re: cvs commit: httpd-2.0/modules/filters mod_deflate.dsp
Quick appologies that I hadn't followed up, my 'play' box which handles my list mail had a nifty hard drive failure that took me offline for the rest of the month :) We need a method to determine the library is available and 'enable' the module when this is so. There are some other side effects about compile flags that I'm somewhat concerned about. We can discuss this week on list - again sorry for -0- response for the last two weeks. Bill At 02:56 PM 1/21/2004, André Malo wrote: * [EMAIL PROTECTED] wrote: nd 2004/01/21 12:55:22 Modified:.Makefile.win modules/filters mod_deflate.dsp Log: revert the zlib.lib linkage patch. Bill Rowe said, it's worse than before. However, alternative solutions and more explanations are appreciated. Bill? :) nd
Re: cvs commit: httpd-2.0/server core.c
Uhmmm, this isn't an MMN bump :) If you were adding this new structure *type* as a member of another structure (say as the last member of the conn_rec) and the structure grew (in such a way that folks could be blindly oblivious to the fact that conn_rec just got a bit bigger), that's an MMN bump. It's not the case here. MMN bumps are for module authors who must be pedantic, e.g. they create their own Apache structures, e.g. conn_rec's and pass them around. When a module does something like that, it needs to be alerted that the structures that it creates might not be 100% binary compatible. MMN bumps are for producers of apache-like structures, not for the consumers who trust the elements they need to retrieve from the structures are still present in the new version. Bill At 04:03 PM 1/25/2004, [EMAIL PROTECTED] wrote: nd 2004/01/25 14:03:38 Modified:.CHANGES include ap_mmn.h ap_release.h httpd.h server core.c Log: Add core version query function ap_get_server_revision and accompanying ap_version_t structure (minor MMN bump). The function is similar to apr_version() and allow for exact querying of the core revision level. Revision ChangesPath 1.1377+4 -0 httpd-2.0/CHANGES Index: CHANGES === RCS file: /home/cvs/httpd-2.0/CHANGES,v retrieving revision 1.1376 retrieving revision 1.1377 diff -u -u -r1.1376 -r1.1377 --- CHANGES 25 Jan 2004 15:40:07 - 1.1376 +++ CHANGES 25 Jan 2004 22:03:38 - 1.1377 @@ -2,6 +2,10 @@ [Remove entries to the current 2.0 section below, when backported] + *) Add core version query function (ap_get_server_revision) and + accompanying ap_version_t structure (minor MMN bump). + [André Malo] + *) mod_rewrite: EOLs sent by external rewritemaps are now consumed as whole. That way, on systems with more than one EOL character rewritemap programs no longer need to switch stdout to binary 1.63 +2 -1 httpd-2.0/include/ap_mmn.h Index: ap_mmn.h === RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v retrieving revision 1.62 retrieving revision 1.63 diff -u -u -r1.62 -r1.63 --- ap_mmn.h 1 Jan 2004 13:26:16 - 1.62 +++ ap_mmn.h 25 Jan 2004 22:03:38 - 1.63 @@ -118,6 +118,7 @@ * 20030821 (2.1.0-dev) bumped mod_include's entire API * 20030821.1 (2.1.0-dev) added XHTML doctypes * 20030821.2 (2.1.0-dev) added ap_escape_errorlog_item + * 20030821.3 (2.1.0-dev) added ap_get_server_revision / ap_version_t */ #define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */ @@ -125,7 +126,7 @@ #ifndef MODULE_MAGIC_NUMBER_MAJOR #define MODULE_MAGIC_NUMBER_MAJOR 20030821 #endif -#define MODULE_MAGIC_NUMBER_MINOR 2 /* 0...n */ +#define MODULE_MAGIC_NUMBER_MINOR 3 /* 0...n */ /** * Determine if the server's current MODULE_MAGIC_NUMBER is at least a 1.81 +14 -3 httpd-2.0/include/ap_release.h Index: ap_release.h === RCS file: /home/cvs/httpd-2.0/include/ap_release.h,v retrieving revision 1.80 retrieving revision 1.81 diff -u -u -r1.80 -r1.81 --- ap_release.h 1 Jan 2004 13:26:16 - 1.80 +++ ap_release.h 25 Jan 2004 22:03:38 - 1.81 @@ -59,6 +59,8 @@ #ifndef AP_RELEASE_H #define AP_RELEASE_H +#include apr_general.h /* stringify */ + /* * The below defines the base string of the Server: header. Additional * tokens can be added via the ap_add_version_component() API call. @@ -73,9 +75,18 @@ */ #define AP_SERVER_BASEVENDOR Apache Software Foundation #define AP_SERVER_BASEPRODUCT Apache -#define AP_SERVER_MAJORVERSION 2 -#define AP_SERVER_MINORVERSION 1 -#define AP_SERVER_PATCHLEVEL 0-dev + +#define AP_SERVER_MAJORVERSION_NUMBER 2 +#define AP_SERVER_MINORVERSION_NUMBER 1 +#define AP_SERVER_PATCHLEVEL_NUMBER 0 +#define AP_SERVER_ADD_STRING -dev + +/* keep old macros as well */ +#define AP_SERVER_MAJORVERSION APR_STRINGIFY(AP_SERVER_MAJORVERSION_NUMBER) +#define AP_SERVER_MINORVERSION APR_STRINGIFY(AP_SERVER_MINORVERSION_NUMBER) +#define AP_SERVER_PATCHLEVEL APR_STRINGIFY(AP_SERVER_PATCHLEVEL_NUMBER) \ + AP_SERVER_ADD_STRING + #define AP_SERVER_MINORREVISION AP_SERVER_MAJORVERSION . AP_SERVER_MINORVERSION #define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION . AP_SERVER_PATCHLEVEL #define AP_SERVER_BASEVERSION AP_SERVER_BASEPRODUCT / AP_SERVER_BASEREVISION 1.206 +19 -0 httpd-2.0/include/httpd.h Index: httpd.h === RCS file:
Re: [2.0.48] ap_log_error slow on win32
Stas, we attempt to lock all writes to a file whenever we have a file opened for append, as unix has this behavior naturally while Win32 does not. I'd focus on the speed of obtaining that lock. I'd noticed similar before, myself, and 1/2 suspect that the lock is also flushing the file from cache. Bill At 09:13 PM 1/19/2004, Stas Bekman wrote: Kurt George Gjerde wrote: Hi, Tested under mod_perl 2 I found $r-log_error (interface to ap_log_error) to be substantially slower than printing directly to STDERR. Is this a known problem? Please see: http://www.mail-archive.com/dev%40perl.apache.org/msg06003.html Make sure to read the followup: http://www.mail-archive.com/dev%40perl.apache.org/msg06031.html The Unix implementation seem to be much faster (only about 1.5 times slower than direct stdio print vs. win32 which is about 16 times slower). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: page out of date
At 11:32 AM 1/26/2004, Aryeh Katz wrote: http://apache.get-software.com/httpd/binaries/win32/README.html doesn't have the correct version numbers. I see this is fix is committed already, thank you for the observation. As an aside, would it make more sense to use SSI, and get the version number from the SERVER_SOFTWARE environment variable (I assume apache.org will always be running the most up to date version of apache). chuckle Short of the fact we usually run a more-up-to-date than current version (some form of -dev, often 2.1-dev), we have two different current versions, that of 1.3 and of 2.0. I await feedback before blessing these official releases - and this time there was no feedback to be blessed. Became current just by default. Bill
FileSystem v.s. Other Resources [was configurable Location?]
At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote: But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether this should be configurable or not. Yes, I'm one who will agree with your devil's position :) I know the problem you are trying to solve, and changing the behavior of Directory isn't quite the solution... Issue 1: Walking the filesystem (the stat aspect of Directory and File) for something that doesn't live there is stupid :) We agree, and this must be fixed in 2.1 Issue 2: Matching directories when something is outside of the filesystem is simply wasteful, and here too we agree. The problem is that you want to add layers of additional directives, which would change the behavior of Directory or Location , in ways that would allow the user to seriously compromise what they had explicitly configured for security. This is unwise. Let's look at the two issues above; Effect/Issue 1: Bypassing the filesystem canonicalization would be very bad on certain platforms such as windows, depending on case sensitivity, etc. It would also bypass *user configured* options such as avoiding symlinks. Effect/Issue 2: Bypassing the directory block walk would ignore the very Directory sections that the user explicitly put in their config. This too is bad. There is only one way to avoid these consequences, and still save ourselves the pain of the filesystem walk and Directory block handling... === Break out file handling as a separate component === I've proposed in the past the simple directive FilesystemMount /path/to/files Consider the existing directive, DocumentRoot, as shorthand for; Location / FilesystemMount /old/root/ /Location Also consider the Alias /foo /path/to/bar directive as shorthand for; Location /foo FilesystemMount /path/to/bar /Location But wait, there is more :) We have a default handler. Simply modify it to be the default_file_handler. Insert it ONLY if the appropriate FilesystemMount directive exists in the particular location block. What happens to requests that don't have a FilesystemMount block, and don't have another handler (e.g. SetHandler info-handler or whatever)? These requests would error out with a 500 - there is no way for the server to handle them. What happens to our old default handler (inserted at all times?) It becomes a simple error-500 handler if nothing else intercepts the request. Note that the exact semantics could change (my naming isn't all that great either) - but the key detail is that mount directives within a given Location are much safer and easier to follow than arbitrary Mount src dst directives which may be order and/or length dependent, creating confusion for the user. So in short, veto on the original proposal to give users gun to point at foot. +1 on the concepts that we quit interrogating the filesystem when the user wants to serve non-files, and quit walking directory blocks for things that do not live in directories. Let's do this in 2.1 by splitting out the file system, and if the filesystem module isn't handling a request, it won't be serving content but also won't be invoking the directory walk or stat-ing files. Oh last observation - it should become (in 2.1) nearly impossible for folks to just bork around with the contents of r-filename and r-finfo, first by stripping them from the request rec, and second by providing an API to the filesystem module that lets another module link into another file. That API would prevent module authors from bypassing the filesystem module's internal security. If they want different behavior, they can plug in their own backend handler to deal with the whole request process. Bill
Re: adding output filters in quickhandler
Quick handlers are not for filtering content. Quick handlers assume all responsibility for the request, e.g. proxy content servers. In fact this particular hook was debated for quite a while (with some believing it was inherently a bad thing.) I don't believe that redirects have the opportunity to do a quick handler, because the quick handler exists to map a request 1:1 to a result. Bill At 03:38 PM 1/27/2004, Brian Akins wrote: Possible bug: If I add an output filter in the quickhandler for something like /foo/ and later mod_dir changes it to /foo/index.html, my output filter is never ran. Is this why mod_cache cannot cache things that end in /. This just seems broken... -- Brian Akins Senior Systems Engineer CNN Internet Technologies
Re: [SECURITY-PATCH] cygwin: Apache 1.3.29 and below directory traversal vulnerability
At 05:45 PM 2/4/2004, Roy T. Fielding wrote: -1. Reject the request with a 400 error instead. ++1 to Roy's suggestion. I believe that Win32 may accept the back slash (with the changes proposed for the cygwin port.) However ... here's the trick ... the cygwin httpd port is emulating Unix, so it should behave as a unix port. Bill
Re: Capabilities to provide UDP (not TCP) services with Apache
I'm totally confused now :) Do you want Apache to handle the UDP request as an HTTP request? Or do you want a UDP port that does something else? First if you want a pool of UDP listeners, explore the MPM - it's the MPM's job to dispatch requests from TCP, so it would make sense to build upon another MPM to handle the connections. Second if you want to handle a protocol other than HTTP, see mod_echo as an example (trivial of course, just as the echo protocol is trivial.) Bill At 06:22 PM 2/4/2004, Matthew Gress wrote: I am curious about what it would take to use an alternate protocol at layer 4 with apache. I have already posted to the users list and was referred here. Apache can communicate with several TCP protocols but I have a module project which needs UDP communications as well. I have searched the documentation, archives, and 2.0.48 HTTPD server source for this and all I find are references for beos, testcockets, LDAP, DNS lookups and some OS-related stuff regarding NIS. Oh yeah, and an old SSL exploit apparently made HTTPD open a UDP listener too... In any case, I have not found a reference to how to configure apache to do this and need to know where I should start to create or adapt for this functionality. We realized that we might have to code this personally to make this work, but would rather not if it is already in existence. Another question I have is, can we create a module that services UDP connections without hitting the cental apache server code. Thanks! Matthew Gress
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 10:43 AM 2/5/2004, Greg Marr wrote: At 10:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: Thanks for the feedback, Will. William A. Rowe, Jr. wrote: At 03:39 PM 2/4/2004, [EMAIL PROTECTED] wrote: But then if I play devil's advocate, someone could see the new directive and turn it on when it's not appropriate and cause Bad Things to happen. Mainly I'm looking for comments on whether this should be configurable or not. Yes, I'm one who will agree with your devil's position :) I know the problem you are trying to solve, and changing the behavior of Directory isn't quite the solution... I'm only changing Location ... Directory is unaffected. Well, that's not entirely true. The Directory is affected indirectly, because it no longer applies. The behavior currently is: it applies to everything it matches. This would change it to: it applies to everything it matches unless it also matches a Location, in which case it doesn't apply. Right - I understand. I'm saying (as you pointed out) that it's too dangerous :) Defies the principle of least surprise. They configure Dir blocks only to have them ignored. The only safe way to do what you are suggesting, is to yank the default file handler from under the request anytime the user has overridden the Dir checks. Simplest way to do that is bind them together as a filesystem module. Oh, the same problems (of yanking Dir out from under the user) would be true of the CGI handler, as well as third party modules that do things with the filesystem. It would be important that they could explicitly enable the module to add Dir handling. Which brings us back to square one. I'd actually argued a long time ago that a module that handles requests outside of the filesystem should be responsible for bypassing the Dir handler itself. For example, mod_proxy satisfies the map_to_storage hook on it's own, therefore never hitting Dir . Bill
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 09:22 AM 2/5/2004, [EMAIL PROTECTED] wrote: Effect/Issue 1: Bypassing the filesystem canonicalization would be very bad on certain platforms such as windows, depending on case sensitivity, etc. It would also bypass *user configured* options such as avoiding symlinks. only for Location If the admin is telling us the content is outside the filesystem, I don't think filesystem canonicalization or symlinks are relevant. But the question is how the admin communicates that to us. You are suggesting we allow Location virtual /not/a/file to say it's outside of the file system. *However* are you preventing a file from being served? Guess that is the gist of my concern. Effect/Issue 2: Bypassing the directory block walk would ignore the very Directory sections that the user explicitly put in their config. This too is bad. This is only for Location . There is no change to the behavior of Directory . to avoid these consequences, and still save ourselves the pain of the filesystem walk and Directory block handling... I'm only changing Location Wait - so you say. But the effect is to disable Directory block handling, am I confused on this point??? If you ignore valid Directory blocks because somewhere else the admin says Wait - this location is virtual! then are you also preventing those files from being served? If not this is what I suggest is a violation of the principal of least surprise. === Break out file handling as a separate component === I've proposed in the past the simple directive FilesystemMount /path/to/files At first glance it looks like a key difference is that you are approaching it by saying that it's OK to have Location map to a real filesystem and providing config to explicitly specify the mapping. I'm advocating going the other way and allowing Location to be treated as if it is really outside of the filesystem. Here's what I'm suggesting; 1. Everything in Apache is at some location. Location is a predictable factor because every URI becomes a location. A Location block will always override all other configurations, location blocks are always applied as least-to-most significant if they are absolute, and then pattern matching location blocks are applied after that. 2. Some things in Apache are in the Filesystem, some are in JK, some are in an application (a cgi with PATH_INFO). These aren't always 1:1 to the filesystem, except in the case of filesystem-based modules such as our default handler and the current cgi modules. 3. If something is in the Filesystem, then Directory and Files should be applied. If something is not in the filesystem, than no, it should not, and that other backend (e.g. proxy) should have it's own container blocks to deal with the resource (e.g. Proxy blocks.) Overloading can become a very confusing a dangerous game for admins to properly configure their servers. 4. If something is not in the Filesystem, there should be no way that our own CGI handler or default file handler should be allowed to handle the request. If Apache 5. Whatever resource (Filesystem or what have you) that claims to own the resource for config block processing should be the only available handler to deal with the resource on the back end. Jumping from one resource context in the configuration phase to another resource resource in the handler phase is very dangerous. Beyond what I've detailed above, I'm flexible about how it works/what the various directives are, etc. Bill
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 09:47 AM 2/6/2004, [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: At 12:17 PM 2/5/2004, Joshua Slive wrote: I do, however, agree that doing a directory-walk on virtual resources is not nice. But my opinion is that virtualness is a property of the resource, and hence should be designated when selecting the resource. That is why I suggested changing SetHandler rather than Location. And perhaps I'm going way off in left field here, but why should this be user-configurable at all? Shouldn't the (for example) server-status handler know itself that it is a virtual handler, and therefore indicate that the directory-walk should be skipped? For example, yes. But on the other hand, what prevents someone from removing the server-status handler in the fixups phase and tricking us into serving a file. sounds like we're getting into defense mechanisms against hypothetical malicious modules... a loosing battle IMO Malice? Nah, defending against badly written or inherently insecure modules. But much more to the discussion at hand... ...will administrators grok when Location virtual /foo is a safe bet? Will it proliferate in example configurations in the wild, in unsafe ways? I think we can all presume it will. Look at our frustrations with users that have essentially open proxy configs, which they set up by following examples that proliferate out there. Just playing defense here. Bill
Re: frustrating build experience *nix/windows
At 09:44 AM 2/6/2004, Aryeh Katz wrote: In the 1.3 environment I was able to use the --shadow configure option to use the same source tree for multiple os's. This was quite valuable, as one source code change was needed for all platforms. However, the --shadow option is gone in 2.0. That's why there are two source packages, windows and UNIX. Actually that's not the reason. The two reasons are: 1. line endings; msvc and msdev studio hate several files with unix line endings and either fail all together (nmake makefile) or produce erroneous results (emitted diagnostic line numbers from .c source files etc.) The win32 package uses srclib/apr/build/lineends.pl to mop text files from one to the other form. Unless you are using a linux toolchain, or working on a volume that supports two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this issue seems that it would continue to plague you. 2. build files; this shouldn't be a hassle for you, it simply includes generated win32 exported makefiles and makefile dependencies from .pdb projects, along with the awk result .rc version files. These aren't present in the Unix build, and are honestly not required to build the project if you use Visual Studio later than version 5. Can someone tell me why the --shadow option was removed? Not I - other than we ditched our over-abused configure script in favor of autoconf's inherent features. As you suggest, --srcdir does the same thing. Bill
Re: frustrating build experience *nix/windows
If I grok what you are asking it would be nice if win32, too, would support VPATH builds with a --srcdir like argument - and throw it's generated files in another directory tree. Did I get the point? This seems doable. Bill At 12:44 PM 2/6/2004, you wrote: William A. Rowe, Jr. wrote: At 09:44 AM 2/6/2004, Aryeh Katz wrote: In the 1.3 environment I was able to use the --shadow configure option to use the same source tree for multiple os's. This was quite valuable, as one source code change was needed for all platforms. However, the --shadow option is gone in 2.0. That's why there are two source packages, windows and UNIX. Actually that's not the reason. The two reasons are: 1. line endings; msvc and msdev studio hate several files with unix line endings and either fail all together (nmake makefile) or produce erroneous results (emitted diagnostic line numbers from .c source files etc.) The win32 package uses srclib/apr/build/lineends.pl to mop text files from one to the other form. Unless you are using a linux toolchain, or working on a volume that supports two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this issue seems that it would continue to plague you. This might be the issue *nix to windows. I was having trouble the other direction. After my windows builds my *nix builds were toast. 2. build files; this shouldn't be a hassle for you, it simply includes generated win32 exported makefiles and makefile dependencies from .pdb projects,along with the awk result .rc version files. These aren't present in the Unix build, and are honestly not required to build the project if you use Visual Studio later than version 5. Actually, this was exactly my problem. apr.h, apu.h and a whole bunch of other files were generated by windows (and at least I couldn't get it to clean up). Once those header files get included by the *nix packages (despite the fact they have working apr.h etc in their own tree), the sources won't compile. -- Aryeh Katz SecureD Services http://www.secured-services.com/ 410 653 0700 x 2
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 04:34 PM 2/6/2004, [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
I do, however, agree that doing a directory-walk on virtual resources is
not nice. But my opinion is that virtualness is a property of the
resource, and hence should be designated when selecting the resource.
That is why I suggested changing SetHandler rather than Location.
And perhaps I'm going way off in left field here, but why should this be
user-configurable at all? Shouldn't the (for example) server-status
handler know itself that it is a virtual handler, and therefore indicate
that the directory-walk should be skipped?
I like it! assuming we tweak it to be the module's responsibility to declare this
property, vs. strictly the handler's (too late).
Modules can do that today with some very trivial code...
static int virtual_map_location(request_rec *r)
{
int access_status;
/* Test that SetHandler forced to this content
* otherwise skip it.
*/
if (strncmp(r-handler, info-handler) != 0)
return DECLINED;
/* this info-handler won't deal with the filename
* so null the filename to ensure no file is served.
*/
r-filename = ;
/* Don't let the core map_to_storage hook handle this,
* We don't need directory/file_walk. See mod_proxy.c
* if our own custom Restrictions blocks were needed.
*/
return OK;
}
static void register_hooks(apr_pool_t *p)
{
...
/* Suppress default dir_walk behavior, our module's
* content is virtual.
*/
ap_hook_map_to_storage(virtual_map_location, NULL, NULL, APR_HOOK_MIDDLE);
}
Re: FileSystem v.s. Other Resources [was configurable Location?]
You hit the nail on the head - Alias (and mod_rewrite) cause us the greatest grief in fixing this set of issues. *IF* they all are parsed in the translate name phase we are fine, since map_to_storage is run after translate_name is done. If they are not handled up front we have problems (some translations can occur in the fixup phase, IIRC, which is wrong IMHO.) The other risk, that we reset filename because we might hit the core handler, could be much cleaner if we just failed 500 right out of the core handler any time that dir_walk isn't run against the resource. I recall some arguments to that fix in 2.0 - I'd like to force the hand on that issue in 2.2. Unsetting the r-filename would become unnecessary in this trivial example. Bill At 08:08 AM 2/9/2004, Brian Akins wrote: William A. Rowe, Jr. wrote: At 04:34 PM 2/6/2004, [EMAIL PROTECTED] wrote: /* this info-handler won't deal with the filename * so null the filename to ensure no file is served. */ r-filename = ; \ What if you have something like: Location /dynamic-stuff SetHandler virtual-dynamic-handler /Location Alias /normal/stuff/dyn /dynamic-stuff How would all this affect this situation? IE, we would still need to know that /normal/stuff/dyn/1/2/test.html became /dynamic-stuff/1/2/test.html
Re: frustrating build experience *nix/windows
At 07:43 AM 2/9/2004, you wrote: William A. Rowe, Jr. wrote: If I grok what you are asking it would be nice if win32, too, would support VPATH builds with a --srcdir like argument - and throw it's generated files in another directory tree. Did I get the point? This seems doable. That would be perfect. Do I need to bugzilla this? By rights you should - but I'm already on it as part of revisiting the Win32 build schema (because enabling APR features like IPV6 and httpd conditional features like zlib/mod_deflate and openssl/mod_ssl is difficult today.) It's just one more (worthy) feature to include in win32 specifics. Bill
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 01:37 PM 2/9/2004, André Malo wrote: * William A. Rowe, Jr. [EMAIL PROTECTED] wrote: You hit the nail on the head - Alias (and mod_rewrite) cause us the greatest grief in fixing this set of issues. *IF* they all are parsed in the translate name phase we are fine, since map_to_storage is run after translate_name is done. If they are not handled up front we have problems (some translations can occur in the fixup phase, IIRC, which is wrong IMHO.) No. Alias translations and RewriteRules in servercontext are handled in the translate_name hook. Fixup rewrites (-internal redirects) or mod_alias-redirects in directory context are only triggered by per-directory configuration, which would be skipped in that case. Ahhh of course. The only issue in mod_rewrite could be the Type/Handler forcing which occurs also in fixup, where is the right place for such things (to force something). Don't they result in internal redirects? In that case there is nothing wrong when the internal redirect starts a new request cycle with the modified uri/filename. Bill
Re: [PATCH] configurable Location block speed up
At 03:08 PM 2/9/2004, [EMAIL PROTECTED] wrote: Ben Laurie wrote: [EMAIL PROTECTED] wrote: or Joshua's virtual keyword on Location , which I like better the more I think about it. ooops... s/Joshua/André/ but Joshua has excellent points about virtualness being a property of the handler. Yes, the server-status handler should know that it is virtual, but the handler hook is too late to skip the directory walk. But the mod_status maintainers (i.e. us) know that mod_status is virtual, so maybe it could tell the core earlier somehow. An earlier hook? preferably something at config time since the virtualness doesn't ever change? Isn't this going to be horribly messy? The current system says oi, you - here's a URL, do you handle it? whereas you'd need to have oi, you, here's a pattern that might match a URL you handle, does it?. it should be clean. I'm thinking the module somehow communicates to the core that all its URLs are virtual, i.e., they don't map to the filesystem no way no how not ever. Then we still need the Location /server-status SetHandler status_handler# or whatever it is /Location config/processing to take care of the pattern matching of the URLs, just like today. If both of those things line up, then we can skip the directory walk. Just to be clear: is the idea that you determine the handler (without a directory walk), then determine whether to do the directory walk from that? right. The first part already happens. If so, aren't there cases where the handler gets determined during the directory walk, by .htaccess? certainly. But does it make sense for a given URL to have a handler set by location walk whose content is known to be virtual, and then have yet another handler set during directory walk/.htaccess processing? Absolutely not. In fact, if it's not a file resource, there should never be any file-based .htaccess (it's left as an exercise to the reader to picture a zip file handler which could extract .htaccess information relevant to the zip contents, or an .htaccess resource in a database that corresponse to other database records :-) With the config above, we already determine the handler today during the location walk. The change I'd like to see is that if this happens and also the module declares that its content is virtual, we skip the directory walk/.htaccess. Right on - if the *module* is virtual it should bypass these things. This means you couldn't have Directory /server-status or its .htaccess equivalent do anything if we have the config above, assuming such a directory actually exists and we declared that the status handler generates virtual content. IMO that's goodness because it is confusing as hell to support overlapping Location and Directory blocks*. For me, that falls into the unpredictable results category even though a few of us know what it will do today. * with the possible exception of Location / which is documented as being global. Agreed (Location always wins). What is /server-status - is it a File or a Directory ??? Of course it's neither and flip a coin on what Apache does with it. (Hint, if it isn't found and the leading segments exist as directories, then it is a file, not a directory.) Bill
Re: FileSystem v.s. Other Resources [was configurable Location?]
At 02:11 PM 2/9/2004, [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: At 04:34 PM 2/6/2004, [EMAIL PROTECTED] wrote: Joshua Slive wrote: And perhaps I'm going way off in left field here, but why should this be user-configurable at all? Shouldn't the (for example) server-status handler know itself that it is a virtual handler, and therefore indicate that the directory-walk should be skipped? I like it! assuming we tweak it to be the module's responsibility to declare this property, vs. strictly the handler's (too late) Modules can do that today with some very trivial code... I think I see a problem. No doubt it could be made to work with a simple tweak. SetHandler in the location container sets the handler field in the core dir conf during location walk. ??? I'm not seeing that, the dir/location walk doesn't set up r-handler at all. You can use the SetHandler directive in location or dir contexts. I suppose if it is set in a location, we set r-handler it in the translate_name phase. Even if it's overridden in a Directory block, the Location block it points at would still override it. So this change seems harmless. map_to_storage runs, but r-handler hasn't been updated due to the SetHandler yet. virtual_map_location doesn't know that it owns this URI. An unnecessary directory walk happens. Yes - the module needs to determine ownership in the translate_name phase. core_override_type runs during the fixups phase and sets r-handler to the handler specified in the Location block from the handler field in the core dir config. It's too late to affect the directory walk. Another nit is that every module with virtual content would repeat essentially the same code, other than checking the unique handler name of course, and add to mainline path length on every request by increasing the number of map_to_storage routines. We would depend on each module zapping r-filename. This doesn't bother me for 2.0 if we can save a directory walk. I guess I'm really concerned, after some of the problems and confusion this thread has revealed, about changing the behavior at all in 2.0. If we can get our own core not a file handlers to behave nicely (by fixing r-handler back in the translate_name phase) I would feel better about a minor change. That's a pretty restrictive change that would only affect, mod_info, mod_status etc. Other authors could do likewise if they understand the ramifications. But it seems after reading all of the comments, we aught to make some appropriate design changes in 2.2 so this entire solution is robust without breaking existing modules and possibly introducing security issues. After all, Apache 2.0 should be stable, and we should spend some time breaking the server in 2.1-dev with the eye to releasing a faster, more optimized 2.2. And yup - *every* handler author aught to make the appropriate change, because only they understand what's up with their content, and if it should be walked by dir and file sections, or not. We know mod_info and mod_status don't need to be, so we can code that ourselves. Bill
Nomination, Sander Temme as httpd PMC member
Sander has been a committer for over a year to httpd-test/mod_specweb99 with Greg Ames and Andre Malo. Has also been contributing observations and occasional patches to [EMAIL PROTECTED] about both specweb99 and perl-framework for at least as long, as well as less frequent but useful observations to httpd. With over a year in the httpd-test arena (our subproject) I nominate him as a member of the httpd PMC. I believe PMC participation of the test-dev team is equally important in managing the HTTP server project. Submitted for your consideration; Yours, Bill
Re: Nomination, Sander Temme as httpd PMC member
Sorry folks, was responding to another post that belongs in pmc. We attempt to keep all code discussions open and transparent on dev@, and individuals on pmc@ - sorry especially to Sander for this mis-posted message. drink beverage=coffee size=24oz Bill At 12:45 PM 2/12/2004, William A. Rowe, Jr. wrote: [...] Submitted for your consideration; Yours, Bill
Re: Adding support for SO_BINDTODEVICE
At 12:50 AM 2/13/2004, Ben Greear wrote: Jeff Trawick wrote: Ben Greear wrote: I have need of a web-server which can bind to a particular device, both by binding to the local IP address and also using the setsockopt(... SO_BINDTODEVICE) call. Would there be any chance that such a patch would be accepted into the main tree? sure there's a chance ;) if a patch isn't hard to create and you need such a server anyway, post the patch and let us see what this involves; please note that new features like this should be in 2.1-dev... you didn't mention which level of Apache you were interested in enhancing I'm working on 2.0.48, the latest stable. I assume the patch will port forward to the development version fairly easily. One question I have: I need root priv to SO_BINDTODEVICE. But, it appears to be highly un-cool to run apache as root. So, is there any easy way to get root priv just while running the bind? I will need to bind during the initial listening phase, and also after an accept is done. The only sane answer is to pass the ports back from a parent-process thread that spools em up. but that won't work after the connection is accepted unless you pass them back through a Unix domain socket to be 'blessed' by bindtodevice. Are you certain you need to do this after accept? I would think the incoming request is already bound to a specific adapter. If you only need root creating the listeners on specific adapters, you already have root (heh - even http on port 80 needs root to create the listeners :-) Bill
Re: [PATCH] SSL not sending close alert message
At 04:07 PM 2/23/2004, Joe Orton wrote: On Mon, Feb 23, 2004 at 01:22:05PM -0800, Mathihalli, Madhusudan wrote: Hi, I started working on Justin's idea of creating a EOC bucket - to do a SSL shutdown before the socket close(). But since the ap_flush_conn is called just before closing the socket - I thought of doing the SSL shutdown during the flush itself. Let me know what you think of this patch. This is just back to what we had patches for already: doing an SSL shutdown on any EOF bucket, right? Which is not right since you get an EOS after each HTTP response, not at the end of the connection. Hence the need for a new bucket type to represent end-of-connection differently from EOS. Do we? I suspect that if the http protocol filter knew the difference between keep alive and connection close requests, it should eat non-terminal EOS marks (and pass flush instead?) while still passing a final EOS to the network stack layer? Bill
Re: [PATCH] Windows IPv6
+1, but which warning does 4163 quiet?
At 09:46 AM 2/26/2004, you wrote:
Here's a patch to enable IPv6 on Windows XP 2003.
In addition we'll need to change the setting of
APR_HAVE_IPV6 in apr.hw - seems like we'll need
some awk magic to do that.
Note that enabling IPv6 drags in the need for
the XP or 2003 platform SDK but I don't see
any way around it. I believe the platform SDK can
be freely downloaded from MS for those who want to
do an IPv6 build.
Any comments before I commit to 2.1?
Allan
Index: server/mpm/winnt/child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.26
diff -u -d -b -r1.26 child.c
--- server/mpm/winnt/child.c9 Feb 2004 20:40:51 -1.26
+++ server/mpm/winnt/child.c25 Feb 2004 16:20:51 -
@@ -314,13 +314,17 @@
int wait_time = 1;
int csd;
SOCKET nsd = INVALID_SOCKET;
-struct sockaddr_in sa_client;
int count_select_errors = 0;
int rc;
int clen;
ap_listen_rec *lr;
struct fd_set listenfds;
SOCKET listenmaxfd = INVALID_SOCKET;
+#if APR_HAVE_IPV6
+struct sockaddr_in6 sa_client;
+#else
+struct sockaddr_in sa_client;
+#endif
/* Setup the listeners
* ToDo: Use apr_poll()
@@ -395,7 +399,13 @@
static PCOMP_CONTEXT win9x_get_connection(PCOMP_CONTEXT context)
{
apr_os_sock_info_t sockinfo;
-int len;
+int len, salen;
+#if APR_HAVE_IPV6
+salen = sizeof(struct sockaddr_in6);
+#else
+salen = sizeof(struct sockaddr_in);
+#endif
+
if (context == NULL) {
/* allocate the completion context and the transaction pool */
@@ -415,7 +425,7 @@
if (context-accept_socket == INVALID_SOCKET) {
return NULL;
}
-len = sizeof(struct sockaddr);
+len = salen;
context-sa_server = apr_palloc(context-ptrans, len);
if (getsockname(context-accept_socket,
context-sa_server, len)== SOCKET_ERROR) {
@@ -423,7 +433,7 @@
getsockname failed);
continue;
}
-len = sizeof(struct sockaddr);
+len = salen;
context-sa_client = apr_palloc(context-ptrans, len);
if ((getpeername(context-accept_socket,
context-sa_client, len)) == SOCKET_ERROR) {
@@ -434,7 +444,7 @@
sockinfo.os_sock = context-accept_socket;
sockinfo.local = context-sa_server;
sockinfo.remote = context-sa_client;
-sockinfo.family = APR_INET;
+sockinfo.family = context-sa_server-sa_family;
sockinfo.type= SOCK_STREAM;
apr_os_sock_make(context-sock, sockinfo, context-ptrans);
@@ -465,9 +475,21 @@
DWORD BytesRead;
SOCKET nlsd;
int rv, err_count = 0;
+#if APR_HAVE_IPV6
+SOCKADDR_STORAGE ss_listen;
+int namelen = sizeof(ss_listen);
+#endif
apr_os_sock_get(nlsd, lr-sd);
+#if APR_HAVE_IPV6
+if (getsockname(nlsd, (struct sockaddr *)ss_listen, namelen) == SOCKET_ERROR) {
+ap_log_error(APLOG_MARK,APLOG_ERR, apr_get_netos_error(), ap_server_conf,
+winnt_accept: getsockname error on listening socket, is IPv6
available?);
+return;
+ }
+#endif
+
while (!shutdown_in_progress) {
if (!context) {
context = mpm_get_completion_context();
@@ -479,6 +501,25 @@
}
/* Create and initialize the accept socket */
+#if APR_HAVE_IPV6
+if (context-accept_socket == INVALID_SOCKET) {
+context-accept_socket = socket(ss_listen.ss_family, SOCK_STREAM,
IPPROTO_TCP);
+context-socket_family = ss_listen.ss_family;
+}
+else if (context-socket_family != ss_listen.ss_family) {
+closesocket(context-accept_socket);
+context-accept_socket = socket(ss_listen.ss_family, SOCK_STREAM,
IPPROTO_TCP);
+context-socket_family = ss_listen.ss_family;
+}
+
+if (context-accept_socket == INVALID_SOCKET) {
+ap_log_error(APLOG_MARK,APLOG_WARNING, apr_get_netos_error(),
ap_server_conf,
+ winnt_accept: Failed to allocate an accept socket.
+ Temporary resource constraint? Try again.);
+Sleep(100);
+continue;
+}
+#else
if (context-accept_socket == INVALID_SOCKET) {
context-accept_socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (context-accept_socket == INVALID_SOCKET) {
@@ -490,7 +531,7 @@
continue;
}
}
-
+#endif
/* AcceptEx on the completion context. The completion context will be
* signaled when a connection is accepted.
*/
@@ -607,7 +648,7 @@
sockinfo.os_sock = context-accept_socket;
sockinfo.local = context-sa_server;
sockinfo.remote = context-sa_client;
-sockinfo.family = APR_INET;
+
Re: (97)Address family not supported by protocol causes disk ticking?
At 03:40 PM 2/25/2004, Alexis Huxley wrote: [Mon Feb 16 23:35:33 2004] [warn] (97)Address family not supported by protocol: get socket to connect to listener the ticking is an unexpected hard flush when APR_APPEND causes win32 to file lock for write. Bill
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 09:55 AM 3/4/2004, Greg Marr wrote: /incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. -# ... /dll /incremental:no /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref +# ... /dll /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref ...
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 12:04 PM 3/4/2004, Greg Marr wrote: At 12:00 PM 3/4/2004, William A. Rowe, Jr. wrote: At 09:55 AM 3/4/2004, Greg Marr wrote: /incremental:no is the default, and MSDev will at times remove flags that it finds redundant, even ones that it added itself. It's a bit schizophrenic like that. uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. -# ... /dll /incremental:no /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref +# ... /dll /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref ... Odd, I thought non-incremental was the default, but the help says otherwise. Incremental is the default, for regular and debug, at least in VC6. Why would you not want incremental for a debug build anyway? Greg we are creating the release build there - we create a pdb for unwinding core dumps. It is an optimized binary - incremental is not a healthy way to release a final image. Again, please revert. Bill
Re: win32 on VC++ 5.0
At 09:23 AM 3/5/2004, Steve Hay wrote: Geoffrey Young wrote: I'm trying to get 2.0.48 to compile using VC++ 5.0 (sp1) on win2k (sp4) and am having a few issues. yeah, I know it's old, but I happen to have it around and it's all I have :) anyway, since I'm not a windows guy, some of this might be common knowledge, but I couldn't find anything on google. It's currently at: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm although MS seem to change most of their links every week ;) I hate even including the links as they are staled often. I don't think you need the Platform SDK for VC++ 6.0; I don't know about 5.0. If you do need it, then it's probably just the Core SDK component that you need. You also need IE 5.0 or later to be able to use most of their download sites! Yes. VC5.0's featureset is pre Win2k - pre NT SP3. so using 5.0 ... I get to apr-util/rand.c and it throws this: rand.c C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'HRESULT' : undeclared identifier C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'UUID' : undeclared identifier I've never seen that using VC++ 6.0. I wouldn't expect so and no - the SDK is required for visual studio 5.0 - this wont be the last thing you trip over. - lastly, is it possible/practical to have httpd 2.0 and 2.1 CVS snapshots include the win foo so I can attempt a fairly recent version of everything? I'll second that request. We don't generate .mak files in CVS - it is not practical - the changes are not worth the investment. However, with awk (awk95 works well) in your path, you can use the interactive apache.dsw to build the project under 5.0 - under 6.0 we build on the command line from dsp/dsw 's. Look in the cvs attic of apache-1.3 for any .mak files and you will see why we decided to make them part of rolling the package. http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/ApacheCore.mak?hideattic=0 vs http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/ApacheCore.dsp?hideattic=0 the cvs ,v files are 362k vs 43k w/ about 50 revs each. The delta of a .dsp is legible, for .mak files they are not. . Bill
Re: mod_ssl TLS/SSL upgrade...
Brad I'm plus 1, especially if we can cause libwww to instigate this connection mode for httpd-test and prove that it behaves per the RFC convention. But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'll propose SSL-C and win32 build solutions I've adopted for Covalent's build farm, over the next few days into 2.1. note that the 2.1 rewrite of the autoconf .m4 stuff made thins much worse - I use a simple hack on top of the 2.0 build scripts. When we declare 2.1 baked, we should shift that module back :) My QA folks have done extensive work wrt 2.1 (up to the last two weeks of rapid patches) and have found it very well suited to build under 2.0.48, compared to the 2.0 flavor. Bill At 10:08 PM 3/4/2004, Brad Nicholes wrote: I would like to resurrect an old discussion. About a year and half ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine upgrade capability. It seems that one of the reasons for not back porting it to the 2.0 tree was because there weren't really any clients that supported it. Well I know of at least one now which is Novell's iPrint client and I suspect that there may be others out there. Does anyone see any major issues with backporting this functionality to 2.0? If not then I would like to propose it for back port and see if we can get it done. The attached patch can be applied to the 2.0 branch. HEAD already contains all of the patches. Here (http://www.apache.org/~bnicholes/wget_tls_prelim-1.8.2.tar.gz)is a hacked version of wget that is able to test the functionality. Invoke wget with the -u parameter to allow it to request the TLS/SSL upgraded connection. Brad At 11:46 AM 10/15/2002, [EMAIL PROTECTED] wrote: [snip] The second is SSL upgrade. I have the patches, they haven't been committed yet. I have attached them at the bottom of this message. The reason they haven't been committed, is that I don't have a client to test them with, and I haven't had time to create one. The responses are correct I have checked them in plain text. The place that bugs most likely exist, is the actual upgrade code that does the handshake. This is an important feature, and I would really like to see it in 2.0. I see a couple of very important aspects to this patch: 1) we must have an implementation of connection: upgrade for libwww, since that is the mechanism we use for httpd-test/perl-framework. I don't have such a fix, so I'm just asking the community if anyone has explored that avenue. 2) it has to be maintained. I've looked at this patch, it appears quite correct. I'm going to begin working on applying it to cvs HEAD. I'm not concerned about it quickly appearing in 2.0 since there are no clients right now. I'm much more concerned about it's availability once clients can support it. 3) right now, the ssl code (ssl_engine_io) was already pretty heavily refactored. The patch wasn't easy to apply. We are discussing other refactorings that will make SSL much simpler to follow and far less error-prone. Those will effectively invalidate the effort Ryan has already invested. My proposed solution is to review the patch and apply it to cvs HEAD. Get it committed. Of course there are no test suites right now, and there won't be for a little while yet. But once the code exists, it will be simpler to keep the SSL upgrade facility maintained, and debug it as the clients become available (most especially, libwww exercises through perl-framework.) Any disagreement? The current patch that applies to cvs HEAD is attached. Bill Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: mod_ssl TLS/SSL upgrade...
At 11:11 AM 3/5/2004, Brad Nicholes wrote: I would really like to get the TLS/SSL upgrade functionality into the 2.0.49 release. If Sander is wanting to start the relase on Monday, I would like to do whatever is easiest to get this patch in. -1 - too big a change too late in the cycle. +1 for 2.0.50 Bill
RE: mod_ssl TLS/SSL upgrade...
At 11:19 AM 3/5/2004, Mathihalli, Madhusudan wrote: -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] [SNIP] --On Friday, March 5, 2004 12:20 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'd rather just start the 2.2 release cycle than do that. -- justin I think a lot of good things have gone into the mod_ssl 2.1 - if we start with 2.2, we may still have to back-port the majority of fixes to 2.0 (as customers may not jump immediately to 2.2). Or to say it very simply - only one patch - connection upgrade - didn't really belong in 2.0 - yet it is harder and harder to keep in sync while dancing around that patch. Bill
Re: win32 on VC++ 5.0
At 11:32 AM 3/5/2004, Steve Hay wrote: How do you build on the command line from the .dsp/.dsw's? The win_compiling.html document that Geoff referred to explains either using Makefile.win from the command-line (which presumably requires the .mak files), or else using the .dsp/.dsw files from the IDE. There is no mention of how to use the .dsp/.dsw's from the command-line. look at makefile.win - that is its job. Bill
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 12:37 PM 3/5/2004, Allan Edwards wrote: Looks like MSDEV fooness to me. I changed nothing in the project except adding the eoc file but I can't coax MSDEV into including /incremental:no in the dsp even though it *is* there in the Link Project Options box. this is why I always add sources (in alpha order as some DevStudio versions seem to prefer) by hand. Yes DevStudio is brain dead on this and other points. Bill
Re: [PROPOSAL] Move httpd to the subversion repository
At 03:12 PM 3/13/2004, Sander Striker wrote: On Sat, 2004-03-13 at 21:35, Jeff Trawick wrote: Sander Striker wrote: Hi, I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. So when? Can we get some lead time (7-10 days from the time there is a complete httpd and apr snapshot in subversion to play with) so developers can get clients installed everywhere and have time to address platform issues or changed scripting requirements before the project switches over? Ofcourse. Your idea of giving lead time starting when we have a test snapshot is very sensible. Lets make that 14 days from then, so that everyone has plenty of time to address issues. One issue I immediately foresee... as the GNU, ASF, and SF projects all discovered, full backups by third parties are invaluable. What is the equivalent to rsync, and is it as stable? As I mentioned to the [EMAIL PROTECTED]'ers I would feel much safer moving 2.1-dev over to SVN (with APR 1.0) and leaving 2.0/apr 0.9 alone to the end of their useful life. Bill
Fwd: apxs on Win32
Something test-dev has kicked around that we should pick back up...
Date: Tue, 29 Jul 2003 09:44:45 -0500 (CDT)
From: Randy Kobes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I've been looking at getting apxs for Win32 working on Apache 2.
There's a number of changes needed due to the current reliance on
libtool, so initially I've tried just a pure Win32 version - if
anyone wants to try it, I've put up two files - Configure.apxs
and apxs.in - at http://theoryx5.uwinnipeg.ca/. Running
C:\Some\Path perl Configure.apxs
(in the same directory as apxs.in) will guess at your Apache2
directory (a --with-apache2=... option can be specified to tell
it explicitly), and then an apxs.bat will be created under
C:\Path\to\Apache2\bin\, along with the associated
C:\Path\to\Apache2\build\config_vars.mk.
I've tried using this for the c-modules tests of perl-framework,
and it seems to work OK, with the following diff applied to
a couple of files under perl-framework/Apache-Test/lib/Apache:
===
Index: TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.165
diff -u -r1.165 TestConfig.pm
--- TestConfig.pm 7 Jul 2003 18:42:29 - 1.165
+++ TestConfig.pm 29 Jul 2003 05:51:22 -
@@ -283,7 +283,7 @@
$self-{APXS} = $self-default_apxs;
return unless $self-{APXS};
-
+$self-{APXS} =~ s !/!\\!g if WIN32;
my $vars = $self-{vars};
$vars-{bindir} ||= $self-apxs('BINDIR', 1);
Index: TestConfigC.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigC.pm,v
retrieving revision 1.20
diff -u -r1.20 TestConfigC.pm
--- TestConfigC.pm 31 Mar 2003 06:58:40 - 1.20
+++ TestConfigC.pm 29 Jul 2003 05:51:22 -
@@ -76,7 +76,8 @@
EOF
}
-my %lib_dir = (1 = , 2 = .libs/);
+my %lib_dir = Apache::TestConfig::WIN32 ? (1 = , 2 = ) :
+(1 = , 2 = .libs/);
sub cmodules_build_so {
my($self, $name) = @_;
@@ -135,6 +136,9 @@
my $lib = $self-cmodules_build_so($name);
+my $extras;
+$extras = ' -llibhttpd -p ' if Apache::TestConfig::WIN32;
+
my $fh = Symbol::gensym();
open $fh, $makefile or die open $makefile: $!;
@@ -143,7 +147,7 @@
all: $lib
$lib: $name.c
- \$(APXS) $dversion -I$self-{cmodules_dir} -c $name.c
+ \$(APXS) $dversion -I$self-{cmodules_dir} $extras -c $name.c
clean:
-rm -rf $name.o $name.lo $name.slo $name.la .libs
===
(there's a failure in building one of the tests due to a
missing random-ish function). The tests were configured as
C:\perl-framework Perl Makefile.PL -apxs C:\Apache2\bin\apxs
-httpd C:\Apache2\bin\Apache.exe
The reason for specifying both -apxs and -httpd is related to the
current Apache-Test using the fact that the apxs variable TARGET
specifies the name of the httpd binary (httpd). On Win32 the
binary is Apache.exe, but changing the value of TARGET on Win32
would break assumptions elsewhere that the Apache configuration
file (httpd.conf on Win32 as well) is TARGET.conf. How to handle
this better should be looked at.
Merging this Win32 apxs.in and the one in the httpd sources would
possible, if that was desired.
--
best regards,
randy kobes
Re: 2.0.49 (rc2) tarballs available
At 03:05 PM 3/15/2004, Sander Striker wrote: On Mon, 2004-03-15 at 22:02, André Malo wrote: * Sander Striker [EMAIL PROTECTED] wrote: There are 2.0.49-rc2 tarballs available at: Please inform us of any problems you encounter. Thanks, I'm going to backport the enableexceptionhook docs. Please put them also into the next tag. TB really honest, I think I saw enough +1s for rc2, I was planning on using that for the release. If there are major concerns not to do that, I'll do a rc3, but otherwise I'd like to get this one over and done with. -1 on win32 as folks pointed out the bogus state someone left ssl-std.conf in - so working on that patch now. Only Makefile.win should need pushing. A +1 after the patch should put us on the track for releasing it. Testers? Makefile.win on HEAD and APACHE_2_0_BRANCH should be golden. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/Makefile.win?rev=1.120.2.14 Bill
Re: [PROPOSAL] Move httpd to the subversion repository
At 11:27 AM 3/16/2004, Ben Laurie wrote: Justin Erenkrantz wrote: --On Monday, March 15, 2004 10:52 AM + Ben Laurie [EMAIL PROTECTED] wrote: It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious). We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. I know. Uhm I beg to differ - I care about both issues :) With the repository and its dumps, everything is date-ordered. The revisions are sequential and the dumps only contain the changes for that particular revision. Once the changes are made, they can be signed by the server and rsync'd via a third-party 'secure' server (*only* adding the new revisions). In the event of an intrusion, we can use those read-only dumps to compare against our 'live' repository. Also, if a malicious set of commits occur, we can also *quickly* remove those as everything is identified by a changeset/revision number across the repository (again, not possible with CVS as it has per-file revnums). I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the secure server? That is always a risk - which is why the more offsite copies backed regularly, the better. If there is a barrier to rsync'ing the database, or rsyncing the commit history and auto-layering the main repository history into a mirror repository, I'm very adverse to the proposal. If anyone has a cool bookmark on mirroring svn repositories, please share. It is news to me that the board have expressed this view. No, it's not official, but every time we have an intrusion, we have no useful mechanism of auditing the integrity of our CVS repository as people can modify the RCS files directly and that *has* been a concern brought up by the board on several occasions. With Subversion, it is possible to easily verify the integrity of the repository against backups. -- justin I have yet to be convinced of this. Same here diff -u3 backup/source.c,v live/source.c,v you mean to say there is an equally trivial way to compare two repositories to do post-mortem with svn? If so please share! Bill
docs-2.0/misc/perf-tuning.html stale?
All of the following seems stale... no? Compile-Time Configuration Issues Atomic Operations The --enable-nonportable-atomics option is relevant for the following platforms: Solaris on SPARC By default, APR uses mutex-based atomics on Solaris/SPARC. If you configure with --enable-nonportable-atomics, however, APR generates code that uses a SPARC v8plus opcode for fast hardware compare-and-swap. If you configure Apache with this option, the atomic operations will be more efficient (allowing for lower CPU utilization and higher concurrency), but the resulting executable will run only on UltraSPARC chips. We axed this code due to licensing issues --- right? DYNAMIC_MODULE_LIMIT If you have no intention of using dynamically loaded modules (you probably don't if you're reading this and tuning your server for every last ounce of performance) then you should add -DDYNAMIC_MODULE_LIMIT=0 when building your server. This will save RAM that's allocated only for supporting dynamically loaded modules. Harmful if swallowed? We default to a dso-based server now. Bill
RE: 2.0.49 rolled
Win32 dos line-ended/vc5 makefiles/apr-iconv flavor of the *sources* is now at http://httpd.apache.org/dev/dist/httpd-2.0.49-win32-src.zip Win32 builders please test. Binaries to follow. Bill At 06:39 AM 3/18/2004, Sander Striker wrote: I've put the 2.0.49 tarballs up at: http://httpd.apache.org/dev/dist Just a minor side note that it still has #define AP_SERVER_PATCHLEVEL 49-dev I'll go and fix. Done. (I moved the tag, yes) I've replaced the tarballs at httpd.apache.org/dev/dist.
Re: 2.0.49 rolled
At 06:16 PM 3/18/2004, Juanma Barranquero wrote: On Fri, 19 Mar 2004 00:01:23 +0100, Sascha Kersken [EMAIL PROTECTED] wrote: It builds and runs fine on Win2K using Visual Studio .NET 2002. lurking mode=off I've built 2.0.49: - on Windows XP Professional (Spanish Edition) - with Visual Studio .NET 2003 - with OpenSSL 0.9.7d - with Zlib 1.1.4 It builds fine, but I'm getting random crashes on apr_pools.c (function allocator_free, line 327): Unhandled exception at 0x6eec75e6 (libapr.dll) in Apache.exe: 0xC 005: Access violation reading location 0x. You built from scratch - can you give us a backtrace according to VisualStudio or Dr Watson? Bill
RE: 2.0.49 rolled - win32 binaries online
At 01:42 PM 3/18/2004, William A. Rowe, Jr. wrote: Win32 dos line-ended/vc5 makefiles/apr-iconv flavor of the *sources* is now at http://httpd.apache.org/dev/dist/httpd-2.0.49-win32-src.zip Win32 builders please test. Binaries to follow. are now up on http://www.apache.org/dist/httpd/binaries/win32/ Please validate scream if broken. Bill
Re: AddCharset filename extensions (again)
Representing a huge palette of code pages - I'd recommend our docs folk consider this and comment or commit. Bill At 10:59 AM 3/19/2004, Zvi Har'El wrote: Dear Apache developers, I sent the following three months ago, but since I got no response, and now 2.0.49 has been rolled without the patch, I resubmit it for you attention: The default httpd.conf includes the lines AddCharset ISO-8859-1 .iso8859-1 .latin1 AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk However, quick look at http://www.iana.org/assignments/character-sets shows that calling the non-latin charsets ISO8859-N by the name latinN is wrong. For example, latin8 is ISO-8859-14, or iso-celtic, and certainly not ISO-8859-8, which is just hebrew! Similarly, latin6 is ISO-8859-10, and not ISO-8859-6, which is arabic! Finally, latin5 is ISO-8859-9, turkish, and not ISO-8859-5, which is cyrillic. latin1-4 are ok, and I didn't find latin7 in this reference at all. I suggest httpd.conf should be fixed accordingly. To make my point clearer, here is the patch: --- httpd-2.0.48/docs/conf/httpd-std.conf.in.~20031011014743~ 2003-10-11 03:47:43.0 +0200 +++ httpd-2.0.48/docs/conf/httpd-std.conf.in2003-12-15 18:47:07.0 +0200 @@ -797,11 +797,15 @@ AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 -AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru -AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb -AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk -AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb -AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk +AddCharset ISO-8859-5 .iso8859-5 .cyr .iso-ru +AddCharset ISO-8859-6 .iso8859-6 .arb +AddCharset ISO-8859-7 .iso8859-7 .grk +AddCharset ISO-8859-8 .iso8859-8 .heb +AddCharset ISO-8859-9 .iso8859-9 .latin5 .trk +AddCharset ISO-8859-10 .iso8859-10 .latin6 +AddCharset ISO-8859-13 .iso8859-13 .latin7 +AddCharset ISO-8859-14 .iso8859-14 .latin8 +AddCharset ISO-8859-15 .iso8859-15 .latin9 AddCharset ISO-2022-JP .iso2022-jp .jis AddCharset ISO-2022-KR .iso2022-kr .kis AddCharset ISO-2022-CN .iso2022-cn .cis I have also included latin7 and latin9, which for some reason absent from IANA, but appear as standard in in the FSF's free recode. BTW, instead of inventing new charset abbreviations like .cyr, .arb, .grk, .heb, I would personally prefer using the IANA (RFC 1345) aliases: .cyrillic, .arabic, .greek, .hebrew, in the same way we use .latin1, .latin2 , etc, but this is a matter of opinion, not bug fix patching. Best, Zvi. -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL If you can't say somethin' nice, don't say nothin' at all. -- Thumper (1942) Friday, 27 Adar 5764, 19 March 2004, 6:53PM
Re: AddCharset filename extensions (again)
At 12:06 PM 3/19/2004, André Malo wrote: * Joshua Slive [EMAIL PROTECTED] wrote: +1 for 2.1 and +1 form leaving 2.0 and 1.3 alone as they are (backwards compat etc). If they are out of spec, fix 2.0 / 1.3 also. The risk to .conf files are changes in httpd that *force* the user to update their existing confs (think authn/authz changes coming in 2.2.) This fix forces them to change nothing in their own conf unless they have a problem with their content. Bill
Re: SEGV in allocator_free
How is this apr? seems you have a pool scope bug causing a double-clear?
Bill
At 12:08 PM 3/19/2004, Mathihalli, Madhusudan wrote:
Hi,
I am trying to test a SSL Proxy server using sslswamp, and I'm running into
the following segmentation fault !
There appears to be some missing error checks in the APR library - here's the
backtrace:
(Apache 2.0.48 - and I haven't tried 2.0.49)
(gdb) bt
#0 0xc1ba2190:0 in allocator_free (allocator=0x601abe90,
node=0x0) at apr_pools.c:374
#1 0xc1ba2fe0:0 in apr_pool_clear (pool=0x60439e68)
at apr_pools.c:746
#2 0x4009fa00:0 in core_output_filter+0x8b0 ()
#3 0x40082b50:0 in ap_pass_brigade+0x130 ()
#4 0xc1f31290:0 in bio_filter_out_flush+0x190 ()
from /opt/hpws/apache/modules/mod_ssl.so
#5 0xc1f31790:0 in bio_filter_out_write+0x190 ()
from /opt/hpws/apache/modules/mod_ssl.so
#6 0xc1fd4540:0 in BIO_write+0x1a0 ()
from /opt/hpws/apache/modules/mod_ssl.so
#7 0xc1fae0d0:0 in ssl3_send_alert+0x770 ()
from /opt/hpws/apache/modules/mod_ssl.so
#8 0xc1fa73a0:0 in ssl3_shutdown+0xe0 ()
from /opt/hpws/apache/modules/mod_ssl.so
#9 0xc1f7c540:0 in SSL_shutdown+0xe0 ()
from /opt/hpws/apache/modules/mod_ssl.so
#10 0xc1f56120:0 in SSL_smart_shutdown+0x40 ()
from /opt/hpws/apache/modules/mod_ssl.so
#11 0xc1f33b60:0 in ssl_filter_io_shutdown+0xd0 ()
from /opt/hpws/apache/modules/mod_ssl.so
#12 0xc1f33da0:0 in ssl_io_filter_cleanup+0x60 ()
(gdb) p node
$1 = (struct apr_memnode_t *) 0x0
(gdb) p index
$2 = 0
(gdb) fr 1
#1 0xc1ba2fe0:0 in apr_pool_clear (pool=0x60439e68)
at apr_pools.c:746
746 in apr_pools.c
(gdb) p pool-allocator
$3 = (struct apr_allocator_t *) 0x601abe90
(gdb) p active-next
$4 = (struct apr_memnode_t *) 0x0
(gdb) p active
$5 = (struct apr_memnode_t *) 0x60439e40
(gdb) p *active
$6 = {next = 0x0, ref = 0x60439e40, index = 1, free_index = 0,
first_avail = 0x60439ed0 `, endp = 0x6043be40 `}
RE: SEGV in allocator_free
At 01:30 PM 3/19/2004, Mathihalli, Madhusudan wrote: -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED] [SNIP] allocator = 0x0, that's bad. You didn't do a full httpd rebuild, so there is no way of telling what pool this is. Can you do a full rebuild (with pool debugging enabled)? Is this vanilla httpd-2.0.48? Pretty much - with some minor fixes for HP-UX, and some SSL fixes that've gone into the 2.0.49 release. (fix mem leak and send the 'close-alert' message) so the mem leak fix is there? if the segfault reoccurs - would you validate that the vanilla 2.0.48 suffered the same segv?
RE: SEGV in allocator_free
At 07:47 PM 3/19/2004, Mathihalli, Madhusudan wrote:
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 01:30 PM 3/19/2004, Mathihalli, Madhusudan wrote:
-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]
[SNIP]
allocator = 0x0, that's bad. You didn't do a full httpd rebuild, so
there is no way of telling what pool this is. Can you do a full
rebuild (with pool debugging enabled)? Is this vanilla httpd-2.0.48?
Pretty much - with some minor fixes for HP-UX, and some SSL
fixes that've gone into the 2.0.49 release.
(fix mem leak and send the 'close-alert' message)
so the mem leak fix is there?
if the segfault reoccurs - would you validate that the vanilla
2.0.48 suffered
the same segv?
Here's the stack trace of the SEGV with 2.0.49:
Frame 14 is apr_pool_clear and so is Frame 1 ! Is there some sort of a recursion
happening ?
This is just one little bit, a subpool likely
#1 0xc1babdc0:0 in apr_pool_clear (pool=0x606cf1c8)
at apr_pools.c:713
#2 0x400b5690:0 in core_output_filter+0x1cd0 ()
in the grand scheme of (apparently) a connection pool clear:
#12 0xc1ebecc0:0 in ssl_io_filter_cleanup+0xd0 ()
from /opt/apache2.0.49/modules/mod_ssl.so
#13 0xc1badb60:0 in run_cleanups (cref=0x60224ec8)
at apr_pools.c:1951
#14 0xc1babca0:0 in apr_pool_clear (pool=0x60224ea8)
at apr_pools.c:693
#15 0x4005c940:0 in worker_thread+0x5a0 ()
#16 0xc1b9b220:0 in dummy_worker (opaque=0x600be908)
at thread.c:88
#17 0xc00a21a0:0 in __pthread_unbound_body+0x490 ()
from /usr/lib/hpux64/libpthread.so.1
This proves it to be as subpool...
(gdb) fr 1
#1 0xc1babdc0:0 in apr_pool_clear (pool=0x606cf1c8)
at apr_pools.c:713
713 in apr_pools.c
(gdb) p *pool
$6 = {parent = 0x60224ea8, child = 0x0, sibling = 0x60459268,
ref = 0x60224eb0, cleanups = 0x0, allocator = 0x601cafb0,
subprocesses = 0x0, abort_fn = 0, user_data = 0x0, tag = 0x0,
active = 0x606cf1a0, self = 0x606cf1a0,
self_first_avail = 0x606cf230 `}
of this pool ...
(gdb) fr 14
#14 0xc1babca0:0 in apr_pool_clear (pool=0x60224ea8)
at apr_pools.c:693
693 in apr_pools.c
(gdb) p *pool
$8 = {parent = 0x6001f9f8, child = 0x0, sibling = 0x60222e88,
ref = 0x60226ed8, cleanups = 0x605d42a0,
allocator = 0x601cafb0, subprocesses = 0x0, abort_fn = 0,
user_data = 0x0, tag = 0x40037220 transaction,
active = 0x605d01c0, self = 0x60224e80,
self_first_avail = 0x60224f10 `}
which is likely a child of the process pool.
Suggestion - as a subpool it is cleared by the subpool mop-up, followed
by an ugly explicit release in core_output_filter.
Re: Win32DisableAcceptex
At 08:42 AM 3/22/2004, Bill Stoddard wrote: Shouldn't it instead be Win32DisableAcceptex on|off To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but it makes sense. or easier to parse and consistant w/ mmap/sendfile; EnableWin32AcceptEx on|off [default: on if supported] You might leave the Win32DisableAcceptEx as is, for 2.0 - in case users add that directive in the coming weeks. But I would mark it deprecated already and add the EnableFoo flavor for consistancy. Bill
Re: cvs commit: apache-1.3/src/os/win32 mod_rewrite.dsp
stoddard2004/03/22 10:51:29 --- mod_rewrite.dsp 23 May 2003 02:47:50 - 1.21 +++ mod_rewrite.dsp 22 Mar 2004 18:51:29 - 1.22 -# ADD LINK32 kernel32.lib /nologo /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:Release/mod_rewrite.so /base:@BaseAddr.ref,mod_rewrite /opt:ref +# ADD LINK32 kernel32.lib ws2_32.lib /nologo /subsystem:windows /dll /debug /machine:I386 /out:Release/mod_rewrite.so /base:@BaseAddr.ref,mod_rewrite /opt:ref as mentioned last week, /incremental:no MUST be explicitly stated in the .dsp for the release build - because /debug will turn it on (and it's not wanted.) BUT the IDE will insist on stripping it, because it believes the flag is redundant - thanks again to tools too smart for out own good :( Please fix. Bill
Re: [PATCH]: emulate_sendfile fix [WAS]: File buckets v. core_output_filter
At 03:42 PM 3/22/2004, Bojan Smojver wrote: You are correct, it is probably an expensive operation. The other way would be to know the position within a file and compare it to the one that we should go to. If they are the same, do nothing. I smell future bugs brewing - remember the handle may be dupped. There is fgetpos() in ANSI C, but I'm not sure what the equivalent in APR is and how expensive it is. That would be 2 kernel calls instead of one - always a losing proposition. Bill
Re: apr_pool_cleanup_register question..
At 10:15 AM 3/27/2004, Esteban Pizzini wrote: Hi, I have add this to post_config handler: apr_pool_cleanup_register(p, NULL, module_clean_up, apr_pool_cleanup_null); because I want to know when Apache is shutting down to do some things in my module... It works ok when apache shutdown, but it´s called when it starts too... :( I think this happens because apr_pool_cleanup_register registers functions to be called when a pool is cleared or destroyed, so when apache start I suppose that the pool is cleared.. is there a way to get my function called only when apache shutdown??? Well if you backtraced to the process pool yes. However a dynamic module is loaded, unloaded and reloaded. It's unloaded again before the process pool cleanups are invoked. so short answer - you don't want it to behave as you described. Bill
RE: Win32DisableAcceptex
At 05:10 AM 3/29/2004, Tikka, Sami wrote: -Original Message- From: Bill Stoddard [mailto:[EMAIL PROTECTED] Please double check then check again. This sounds a lot like a dynamic ip address issue. The machine is using static IP address but the DHCP service was also running. I disabled it but the hang with WSAEHOSTDOWN error still occurs every few hours. Actually, apache is running with -DONE_PROCESS at my client's. That is because I wanted to be able to detect and report any possible crashes. So it is not an issue with socket inheritance. Good to know! I have also made a small patch that checks if the GetOverlappedResult() in winnt_accept() fails, apache logs the error and calls exit(). This seemed to help the customer quite a bit. Usually the the newly started apache instance also got this problem and exited but after 3 or 4 new restarts the hang was over and apache operated normally. Good solution - for parent/child setups we ximply need to exit with a specific AP_ERROR_NETRESET code to tell the parent to recreate the listeners. I was wondering if it would help to just close the listening socket and createbindlisten a new one instead of doing a full-blown restart. You cant - thats why Apache is structured with a parent/child setup. Although it's 1:1 now, we have plans to go 1:many - the child cannot create the listen socket. Of course, now that I know the listening socket is normally inherited from the parent process, I think closing it and making a new one might be very tricky... Perhaps a graceful restart would be enough but there was no way to initiate that from the child process, right? Of course - child exit()s. But if you don't want to wait - we need another custom service signal (we use 128 (?) for graceful, so use 129 to signal that the network listeners are borked and do a graceful w/ fresh sockets.
Re: mod_log_forensic?
At 06:49 AM 3/29/2004, Jeff Trawick wrote: Ben Laurie wrote: Jeff Trawick wrote: solution 4: add some suitable API to APR 0.9 and implement on all platforms Surely not returning the value from the inc is broken anyway? And a harmless change even if you don't consider it broken? a) agreed Let me remind that although most platform compilers and linkers are agnostic to the retval, some may optimize in such a way that adding or eliminating a retval from an exported function declatation could break binary compatibility. I don't care either way - just being pedantic in the declaration. If we didn't toss out apr 0.9.5-final then this is a good place to throw it. Add an explicit test in th 2.0.x flavor of mod_unique_id to scream that apr 0.9.5 released or later 0.9 is required. Bill
OT: FULL INSTALL OF APACHE
At 04:10 PM 4/5/2004, dumass wrote: hello. the reason i posted it under that abnoxious title was to be able to see any replies easily. i want to install apache in my Windows 1998 machine. i just waant it for production runs of scripts so that i don't have to ftp them to my site just to see them. i just want help on how to install it correctly. This list is for development of the Apache server, you are looking for the user's list (users-subscribe at httpd.apache.org) Bill.
Re: Internal redirect from an output filter (Apache2.x)
Sumeet Singh wrote: I was wondering if invoking an internal-redirect from within an output filter is legal. I need to do that from my output filter but want to make sure that it conforms to apache2.0 API before I go ahead and design/code it. I presume this is not safe, but is tolerated by die because we will mop up all of the resources very soon thereafter. Note that it is only successful if the headers had not been set up in an earlier call to pass brigade that made it to the protocol stack. I would look at the log results carefully and trace the request to ensure you are satisfied with the processing. It is certainly not recommended, that does not mean it's not possible. Bill
Re: Performance of TransmitFile on Windows Servers with 2.0.49
At 12:50 PM 4/12/2004, Philip Gladstone wrote: Bill, That patch works when the server is running on XP SP 1. It doesn't help when the server is NT4 SP6. I suspect that the TF_WRITE_BEHIND flag is not supported on that platform. When the server is XP, the data rate jumps up to 11MBytes/sec on a 100Mbit network. I would call this a success. My only concern is that if we don't block on the actual send, the transmitted content may be corrupted if the file being transmitted is volitile. p.s. Is it possible to build with VS.NET? I had to hunt down an old machine with VC6! Of course, open up apache.dsw from VS. It converts the dsw/dsp files to a sln and some vcproj files. Bill
Re: Any 1.3.30 tarball feeback??
At 12:33 PM 4/12/2004, Jim Jagielski wrote: Any comments on the 1.3.30 release candidate tarball? The mod_rewrite.dsw was patched to find the ws2_32.lib required when we modified rewrite. Unfortunately, the .mak file was not updated at the same time. IDE builds (what I tested a week ago) work just fine, but command line builds on win32 were broke. My inclination, if nobody disagrees, is to commit the .mak file updates and push the tag, rerolling those files into the 1.3.30 .tar.gz and including them as fixed in the .msi/.exe win32 installers. Being derrived files which are nothing more than gatekeepers (it builds or it doesn't, and does not change functionality) I'm not seeing a reason to toss this tag. Thoughts? Bill
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
++1 - if we can correct that directive's name on the way in. Bill At 04:09 PM 4/14/2004, you wrote: I'd like to propose that I simply commit the revised patch to CVS for us to poke around with/test/review, etc... My guess is that we'll ship with something similar and this will provide, at least, a nice framework.
Fwd: Re: 1.3.29 remote root exploit? (fwd)
FYI issue closed. At 08:11 AM 4/16/2004, felix k sheng wrote: William, Thanks so much for getting back to me. After sending that in, I had the great idea (ok... I'm slow... :) to turn the hex numbers into ascii and lo and behold it was just that perl script. I *thought* that that meant it presupposed the hackers ability to have arbitrary code already running (as opposed to the code giving him the ability to execute that arbitrary code) but still wasn't sure. Thanks again for letting me know the scoop on this. I can breathe easy again. felix On Thu, Apr 15, 2004 at 08:14:21PM -0500, William A. Rowe, Jr. wrote: Date: Thu, 15 Apr 2004 10:17:26 -0400 From: felix k sheng [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: 1.3.29 remote root exploit? Hello, I run several sites using 1.3.29 and came across this page on the net: http://secu.zzu.edu.cn/modules.php?name=Newsfile=articlesid=413 which claims to be a remote root exploit. Is this a real threat or is it bogus? Please let me know, thank you! Felix this is a very serious theat, to you personally if you use this rootkit. However, it is of no significance at all to your Apache servers. Simply do not run this toolkit yourself and your machines are invulnerable :) quoting one resident guru; At 03:00 PM 4/15/2004, Mark J Cox wrote: I looked briefly - and i do wonder if this isn't the root-yourself toolkit. It is; it connects you to a irc server and lets people on the channel run remote commands as you. If this is getting passed around we should really warn about trojan horse exploit code on httpd.apache.org. print $sock USER lemmings +i lemmings :lemmingsv2 NICK lemmings ; -- felix sheng ... [EMAIL PROTECTED]
Local root exploits? [was: remote root exploit?]
A general warning for all [EMAIL PROTECTED] and [EMAIL PROTECTED] subscribers; I run several sites using 1.3.29 and came across this page on the net: http://secu.zzu.edu.cn/modules.php?name=Newsfile=articlesid=413 I want to make clear (after misdirecting the last mail intended to close a security report) that there are several malicious rootkits being advertised to exploit Apache 1.3.29 or other system services that users should beware of (citation, among others, above.) This rootkit roots the box *YOU* use it on, not the Apache server or other system services. Beware of using rootkits to perform vulnerability testing, unless you entirely trust the author of the utility. Some of these rootkits look entirely innocent, until you note that there is an extra pointer deref in the code that invokes the root hexcode locally, even as it passes to a remote ip connection (with no ill effect or reaction on the remote box whatsoever.) Bill
Re: Request for feedback - UseCanonicalPort
Jim, would you post a chart of the now-three proposed behaviors, with the various effects broken out? It would help us all understand why we need a third way. Bill At 02:53 PM 5/11/2004, you wrote: IMO, we need more control over the port number that Apache determines to be canonical beyond that which is provided by UseCanonicalName, simply because there are so many options and permutations which are possible and applicable for different environments. To that end, instead of overloading UseCanonicalName (and breaking the API), I'm working on UseCanonicalPort. Before I spend lots of time on this, I need to get a feel for whether this is an itch others think need scratching and would vote for including in 2.0 (I'm working on 1.3, 2.0 and 2.1 patches)...
Re: Apache config
At 08:21 PM 4/29/2004, C.J. Collier wrote: This project made me think that perhaps Apache should be able to read/write config files that aren't so difficult to parse. :) Many of us agree... Of course, the first example of an easy-to-parse config file format was XML. But I realize that this will not work, since backwards compatibility is important. Hmmm. Backwards compatibility has it's strong points and most definate weaknesses. Even in the current 1.3-2.0 transition, we made the double-quoted arguments for the ErrorDocument directive make a bit more sense in 2.0. Please don't assume that because httpd has always done it that way we aren't open to considering other options. XML parsable config files are on many, many admins and developers minds. Provided there is support for the old format, don't be surprised if someone comes up with XML flavor config files for 2.2 :) If we want to be able to read easier-to-parse config files and we want to keep our backward compatibility, it seems to me that we should write a modular config file parser.I could go into implementation, but that's no fun right yet. Plus, if folks think that it's a good idea, I'm sure I'll spend plenty of time doing just that :) I would expect to learn something from my frustration, too. I wouldn't expect the config module to only read XML and the current format; I would expect the config module to be pluggable, so that we don't have this problem in the future. I know of some Java code that could be made available, and there is also perl and tcl code IIRC. However the best parser is httpd itself, and now that Apache 2.0 reads into a config tree, spitting it out should not be the problem it was back in 1.3. What I want to know is this: Does this list feel that it is a worthwhile use of my time and the time of the devs to spec out, implement, debug and integrate a means of reading arbitrary config data? I realize that it would be a great deal of work, but I can see a great deal of benefit that would come from it as well. I would love to see this effort, if only the code is common to httpd itself. Why have two different parsing schemas, one for httpd, one for another arbitrary utility lib, only to have each mis-recognize the other's files? You are on the right track - I only suggest you look at httpd itself for 1/2 your answer :) Bill
Re: Free Microsoft Compilers
At 10:16 AM 4/17/2004, Jeff White wrote: quote The Microsoft Visual C++ Toolkit 2003 includes the core tools developers need to compile and link C++-based applications for Windows and the .NET Common Language Runtime: Microsoft C/C++ Optimizing Compiler and Linker. C Runtime Library and the C++ Standard Library, including the Standard Template Library. These are the same static-link libraries included with Visual Studio. Microsoft .NET Framework Common Language Runtime. Visual C++ can optionally build applications that target the Common Language Runtime (CLR). /quote Microsoft Visual C++ Toolkit 2003 http://msdn.microsoft.com/visualc/vctoolkit2003/ Thanks for the reference Jeff! Unfortunately it is missing the #1 bit we need to pull off a free build of httpd or apr, and that is nmake :( It looks like, with a free make and awk though, the end user could build all of apache with this compiler. Hmmm, didn't the asf have some sort of make environment (ant anyone :-?) It also means folks have a full set of Win32 API headers/link stubs legitimately obtained, that if someone built under mingw/cygwin/other environments they don't have to grab a full-blown, overstuffed PSDK :) Bill
Re: is it possible to mark buckets to be copied only when to be set-aside?
It's a bug in mod_xslt, if that module trys to set aside a transient bucket. Bill At 12:09 AM 5/19/2004, Stas Bekman wrote: We have the following situation in mod_perl 2 land: we use the same buffer to allocate data in buckets which are passed to the filters. That bucket is created once per request. It works perfectly fine and effective most of the time (we copy from user's program perl space into the re-usable buffer, but no extra allocation happens). But just now one user has reported that it breaks mod_xslt filter, which sets aside the buckets sent from the modperl handler, and then uses them after seeing EOS. By that time the data in all but last bucket is corrupted. Obviously the straightforward solution is to allocate a new buffer for each bucket that mod_perl sends to the filter chain. But this is a huge waste for most users, which don't use this particular kind of output filters that setaside buckets. My question is: Is it possible to mark the bucket's data as volatile or something, so if a downstream filter wants to set them aside it will have to do the copying? At the moment the bucket is created as: bucket = apr_bucket_transient_create(buf, len, ba); and buf is static for the length of the request. Thank you. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: is it possible to mark buckets to be copied only when to be set-aside?
At 08:33 AM 5/19/2004, Cliff Woolley wrote: On Wed, 19 May 2004, William A. Rowe, Jr. wrote: It's a bug in mod_xslt, if that module trys to set aside a transient bucket. Huh? No it isn't. Half of the reason setaside() even exists is to handle transient buckets. I didn't say setaside(), and yes - you identifed the proper behavior (which I doubt the mod_xslt was doing.) Perhaps if I said trys to hold a reference it might have been less ambiguous. Bill
