If-Modified-Since
Has anyone else run into issues with the svn module not working correctly when these headers are set? The example that brought this to light is shown below... [EMAIL PROTECTED]:~/svn/projects$ telnet svn.apache.org 80 Trying 140.211.11.3... Connected to svn.apache.org. Escape character is '^]'. GET /repos/asf/xmlgraphics/fop/trunk/src/documentation/content/doap.rdf HTTP/1.1 Host: svn.apache.org If-Modified-Since: Sun, 26 Nov 2006 13:34:48 GMT HTTP/1.1 304 Not Modified Date: Wed, 14 Feb 2007 13:06:30 GMT Server: Apache/2.2.2 (Unix) SVN/1.3.1 mod_python/3.2.9-unreleased-20060413 Python/2.4.3 mod_ssl/2.2.2 OpenSSL/0.9.7e-p1 DAV/2 ETag: 507515//xmlgraphics/fop/trunk/src/documentation/content/doap.rdf Connection closed by foreign host. The file has been modified at least once in 2007, so the 304 is an error. -- david http://feathercast.org/
Re: 3.0 - Introduction
Paul Querna wrote: I believe the httpd project is ready for a push towards the next major version. I believe everyone involved has learned many things from 2.x. I wasn't here for all of the early 2.x development, so it is very easy to say I am naive in the scope of something like pushing for 3.0. Today, I view the following as largely unsolvable problems with the 2.x architecture: - Async IO will not work in the core without committing more evil hacks, that will make the code harder to understand and follow. - Async IO will not work correctly with filters today. - The module API exposes too many internals of how client IO is done to make small incremental changes. - The HTTP protocol is still married to the core, and there has been very little progress in separating it out. - Performance for many metrics will never be fully on par to async or hybrid async/threaded based servers like lighttpd. - The configuration subsystem does not enable runtime changes, or the ability to easily programmatically extend it. Could we try to address these issues and more with more constrained changes? Very likely. Do I think it would be as fun for everyone involved? Nope. I don't believe that a focus on 3.0 will replace 2.x overnight, just like 2.x has taken many years to replace 1.3.x on new installs. I personally don't view this as a major problem; With time, and if the project is truly better, users will migrate. I do think we need a better strategy for handling dynamic content generators, and things that are not thread safe. I personally believe the push for 3.0 needs to be focused on how to create a positive scratch your own itch for most of the developer. So, in that spirit, what bothers everyone else about 2.x? While I appreciate the work that has been done on our auth model, it's still a nightmare and not as flexible as we should have. I'd like to see us fully support group auth and allowing layered approaches to auth. -- david http://feathercast.org/
Re: mod_wombat
Roy T. Fielding wrote: On Nov 8, 2006, at 10:16 AM, Paul Querna wrote: Brian has expressed interest in brining mod_wombat to the ASF. Is there interest in this PMC to bring it in under us? It sounds like there is enough interest, given the old theory that three committers are enough to support most any module. I don't think it should be part of the default module set, though, at least not until there is a compelling reason. The procedure is: (1) make this thread a formal vote and, assuming that passes (2) fill out the incubation paperwork at http://incubator.apache.org/ip-clearance/index.html and then (3) import the code under httpd/mod_wombat Brian is not currently an httpd committer, but it should not be hard for us to approve module commit access for an ASF member. I am personally +0 on the idea, but my only reservation is that we have too many eggs in one basket already. One of these days, some kind soul will have the energy to build a CPAN-like module registry and distribution mechanism. We've talked about it often enough :-) I even started looking at a replacement for modules.apache.org but it's died a death at present... I am personally interested in it because I believe it could be one of the paths taken for an httpd 3.0 in which Lua was embedded, replacing the config system and other large areas of C code. I am struggling to see what Lua could possibly add (or subtract) from a config system. Using coroutines for request handling might be fun, but placing a coroutine interpreter in the core has all sorts of security implications (not to mention that Lua is a separate code base that we have no control over). However, it would make an interesting experiment. Roy -- david http://feathercast.org/
funny from ac us
Recorded this earlier today - thought people would like it... http://feathercast.org/podcasts/httpd_java.mp3 -- david Have you listened to FeatherCast yet? http://feathercast.org/ Bought the t-shirt? http://www.cafepress.com/feathercast/
Re: [EMAIL PROTECTED] - ASF?
William A. Rowe, Jr. wrote: Projectfolk, http://asylum.zones.apache.org/modules/ Doesn't fully work yet, but is a work in progress following a discussion or two a little while back... Feedback welcome. More interest = more effort gets applied to it :-) Aim is to replace the website. Moving the mailing list makes sense as well. -- david http://feathercast.org/
apreq - apr-util
While doing some work on mod_sparql I found that some of the functionality i had assumed we already had in apr-util was actually available in apreq. Further examination revealed various parts of the library code that I feel really belong in apr-util. I talked briefly with joes and he seemed to be OK with us looking at what parts would be a good fit for apr-util. He indicated that the project was looking to try and alter their code in various ways and so having more of their generic lib code available directly in apr-util may be a win for them as well. I'm not giving specifics yet as I'd like to know if people think we should do it, and then what pieces we should look at moving. The overhead of moving will be minimal and the changes required look to be also minimal. -- david http://feathercast.org/
Re: svn commit: r378394 - /httpd/httpd/trunk/modules/aaa/mod_auth.h
Ruediger Pluem wrote:
On 02/17/2006 12:28 AM, [EMAIL PROTECTED] wrote:
Modified: httpd/httpd/trunk/modules/aaa/mod_auth.h
URL:
http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/aaa/mod_auth.h?rev=378394r1=378393r2=378394view=diff
==
--- httpd/httpd/trunk/modules/aaa/mod_auth.h (original)
+++ httpd/httpd/trunk/modules/aaa/mod_auth.h Thu Feb 16 15:28:44 2006
@@ -54,6 +54,8 @@
APR_DECLARE_OPTIONAL_FN(int, ap_satisfies, (request_rec *r));
+extern APR_OPTIONAL_FN_TYPE(ap_satisfies) *ap_satisfies;
+
typedef enum {
AUTH_DENIED,
AUTH_GRANTED,
-1
This breaks compilation of the trunk on my box after a make clean with the
following error message:
/usr/src/apache/httpd-trunk/srclib/apr/libtool --silent --mode=compile gcc -g
-O2 -pthread-DLINUX=2 -D_REENTRANT
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-I/usr/src/apache/httpd-trunk/srclib/pcre -I.
-I/usr/src/apache/httpd-trunk/os/unix
-I/usr/src/apache/httpd-trunk/server/mpm/worker
-I/usr/src/apache/httpd-trunk/modules/http
-I/usr/src/apache/httpd-trunk/modules/filters
-I/usr/src/apache/httpd-trunk/modules/proxy
-I/usr/src/apache/httpd-trunk/include
-I/usr/src/apache/httpd-trunk/modules/generators
-I/usr/src/apache/httpd-trunk/modules/mappers
-I/usr/src/apache/httpd-trunk/modules/database
-I/usr/src/apache/httpd-trunk/srclib/apr/include
-I/usr/src/apache/httpd-trunk/srclib/apr-util/include
-I/usr/src/apache/httpd-trunk/server
-I/usr/src/apache/httpd-trunk/modules/proxy/../generators
-I/usr/src/apache/httpd-trunk/modules/ssl
-I/usr/src/apache/httpd-trunk/modules/dav/main -prefer-pic -c
mod_access_compat.c touch mod_access_compat.slo
mod_access_compat.c:311: `ap_satisfies' redeclared as different kind of symbol
mod_auth.h:57: previous declaration of `ap_satisfies'
make[4]: *** [mod_access_compat.slo] Fehler 1
make[4]: Verlassen des Verzeichnisses
»/usr/src/apache/httpd-trunk/modules/aaa«
make[3]: *** [shared-build-recursive] Fehler 1
make[3]: Verlassen des Verzeichnisses
»/usr/src/apache/httpd-trunk/modules/aaa«
make[2]: *** [shared-build-recursive] Fehler 1
make[2]: Verlassen des Verzeichnisses »/usr/src/apache/httpd-trunk/modules«
make[1]: *** [shared-build-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses »/usr/src/apache/httpd-trunk«
make: *** [all-recursive] Fehler 1
Configure I used:
./configure --prefix=/usr/src/apache/apache_trunk --with-mpm=worker
--enable-so --enable-mods-shared=all --enable-proxy
--enable-proxy-balancer --enable-cache --enable-disk-cache --enable-mem-cache
--enable-dumpio --enable-proxy-connect
--enable-proxy-ftp --enable-proxy-http --enable-proxy-ajp --enable-ssl
--enable-dav-fs --enable-dav --enable-dav-lock
--enable-rewrite --enable-authnz-ldap --enable-ldap --with-ldap
Reverting it, makes it work again.
So please revert or fix.
Why are people so quick to ask for reversion these days?
I've just committed a change that should make it build on your system.
FWIW I don't think having it declared as it was is correct.
david
docs error
In the trunk docs the link to 'Access Control' in auth.html is broken as access.html seems to not exist in that version. Given the large number of changes maybe it would be a good doc bring to life again?
how does this get changed?
Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all into [ your answer here ]
Re: how does this get changed?
Joshua Slive wrote: On 2/16/06, David Reid [EMAIL PROTECTED] wrote: Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all Require all denied But David, you should really just be including mod_access_compat. I think there are plenty of people here who are going to vote against any release of 2.4 unless configurations like the one above work out of the box with mod_access_compat included. So if you are having problems, it is better to identify them now. I have been using the compat module (which actually worked this time) but I've run into a SIGBUS or SIGILL (latter if not debug build) using the module. Also, unless there is an upgrade path that make sense, is well documented and tested the new auth stuff might as well never have been added. The last set of auth changes left a bad taste in a lot of peoples mouths - shall we try and avoid that this time round? david
auth in trunk is fubar
Had some problems getting a working auth config to let me spend time developing on svn's authz module - when I tried 2.2 the exact same config worked without a problem first time out of the box. Houston, I think trunk's auth code is fubar. Config is as follows, Location /repos DAV svn SVNParentPath /home/david/repos AuthzSVNAccessFile /usr/local/apache2/conf/svn_access AuthType Basic AuthName Subversion repository AuthUserFile /usr/local/apache2/conf/svn_users Satisfy any LimitExcept GET OPTIONS PROPFIND REPORT Require valid-user /LimitExcept /Location Simple GET requests result in a password dialog! with a higher level of output I see that the initial GET request is returned as OK, but it moves onto asking for a password anyways. david
Re: Change in how to configure authorization
Joshua Slive wrote: On 2/10/06, David Reid [EMAIL PROTECTED] wrote: Joshua Slive wrote: On 1/26/06, Ian Holsman [EMAIL PROTECTED] wrote: Hi Joshua: httpd.conf.in has the new structure httpd-std.conf (the one I was looking at) didn't ;( Hmmm... httpd-std.conf doesn't exist in trunk. Just ran into this and couldn't quite believe what I was seeing. I have a similar config on a server and basically unless you're very careful you end up shutting people out! This change in auth seems to make no sense to me. It's adding a lot of complexity to config files. Do we really need to make this change? Really? At the very least can someone please document how config files need to be changed... And no, I don't think having it in a sample config file is enough. No argument on any of that. But the idea is that if you include mod_access_compat, it should be config-file-compatible with older versions. If that isn't true, you should provide details. Well, I had the warnings about the commands being deprecated, but the site didn't work and kept giving me 401 errors. When I changed to the new commands it worked. *shrug* Also, LimitExcept doesn't seem to be working at all. Also mod_authn_dbd still isn't working reliably for me. Works for a short while then stops, starts and stops again at unpredictable intervals... david
Re: Change in how to configure authorization
Joshua Slive wrote: On 1/26/06, Ian Holsman [EMAIL PROTECTED] wrote: Hi Joshua: httpd.conf.in has the new structure httpd-std.conf (the one I was looking at) didn't ;( Hmmm... httpd-std.conf doesn't exist in trunk. Just ran into this and couldn't quite believe what I was seeing. I have a similar config on a server and basically unless you're very careful you end up shutting people out! This change in auth seems to make no sense to me. It's adding a lot of complexity to config files. Do we really need to make this change? Really? At the very least can someone please document how config files need to be changed... And no, I don't think having it in a sample config file is enough. david
limitexcept
So auth changing folks, what replaces limitexcept? It's not working on trunk at present as far as I can tell... david
doap file
I've committed a DOAP file into the trunk repo. This file is referenced by http://projects.apache.org and so we should be keeping it up to date. That site also has details on what it all means and the data that it should contain. david
Re: doap file
Erik Abele wrote: [CC'ing docs to also let them know that there's something to maintain ;-)] On 23.01.2006, at 10:43, David Reid wrote: I've committed a DOAP file into the trunk repo. This file is referenced by http://projects.apache.org and so we should be keeping it up to date. That site also has details on what it all means and the data that it should contain. Since this is not trunk-specific and doesn't really belong to the source and/or release of a specific version, I'd prefer to keep this file somewhere in [1] instead of [2]... that may sound a bit picky but it's a bit cleaner IMHO (accessible via HTTP w/o SVN backend, repo permissions: docs people can access /site/trunk which might not be always true for httpd/trunk, 'nicer' URL for outside usage, etc.)... Comments? The only reason for keeping it under trunk was that having it there it's available to people doing releases. Putting it under site means that those wishing to do a thorough review means they have to have 2 repos checked out. *shrug* I don't really care and so will move it. Cheers, Erik [1] http://svn.apache.org/repos/asf/httpd/site/trunk/docs/ [2] http://svn.apache.org/repos/asf/httpd/httpd/trunk/
[PATCH] clarify use of %s in db queries
This caught me out, so might catch others as well... Index: docs/manual/mod/mod_authn_dbd.xml === --- docs/manual/mod/mod_authn_dbd.xml (revision 369302) +++ docs/manual/mod/mod_authn_dbd.xml (working copy) @@ -61,6 +61,7 @@ titleConfiguration Example/title pThis simple example shows use of this module in the context of the Authentication and DBD frameworks./p +pNB The use of %s in the example is correct. When the username is replaced in the string it will be enclosed inside single quotes./p examplepre #Database Management
Re: [PATCH] Rename to Apache D
Mads Toftum wrote: On Wed, Dec 14, 2005 at 12:21:20PM -0800, Paul Querna wrote: - progname=httpd] ) + progname=d] ) Looks good although I wonder wether it wouldn't be better to go for + progname=D] ) I wondered if we were a big 'D' or a little 'd' as well. +1 on your patch :-) david
Re: 2.3.0 CHANGES
Colm MacCarthaigh wrote: *) Teach mod_ssl to use arbitrary OIDs in an SSLRequire directive, allowing string-valued client certificate attributes to be used for access control, as in: SSLRequire value in OID(1.3.6.1.4.1.18060.1) [Martin Kraemer, David Reid] Should that be PeerExtList rather than OID, in the example? Probably. That code has been changed a few times :-) david
Re: [PATCH] Mixed-cased SSLRequire operators in mod_ssl ?
Joe Orton wrote: On Mon, Sep 19, 2005 at 11:40:24AM +0200, Martin Kraemer wrote: On Tue, Aug 02, 2005 at 07:14:10PM +0200, Martin Kraemer wrote: Of course. BTW: do you think case insensitivity for the keywords is a good idea? I do, but I don't know if it would cause misinterpretation for some existing config files. Like, when someone was looking for a string EQ, will the parser now bail out because it becomes a keyword? I saw no discussion about this question. What does everybody think -- should I apply something like the appended patch to allow for a more liberal syntax, e.g. using AND, oR or In in the example I'm pretty much indifferent, lacking a strong motivation to change it I'd leave it as-is... While I can see this making writing the config easier, I'm not sure it's something we should change... -0 from me as well. david
Re: [PATCH] ssl_ext_lookup #2
Joe Orton wrote: On Wed, Sep 14, 2005 at 11:11:44PM +0100, David Reid wrote: OK, then what about the below. Looks good, +1 with just one nit - it's OK to presume that apr_array_make always succeeds. Thanks David :) (+1 for 2.2.x too) I'll make that small change then commit. Can we just back out the mod_setenvif stuff from the trunk or is someone going to make it work BTW? I didn't add the code, but unless it works then I'm +1 on it's removal. That said, Dirk claims it works for him, so I'd be inclined to leave it in trunk for now, but not in any releases. Martin: does it work for you? david
Re: [PATCH] ssl_ext_lookup #2
Joe Orton wrote:
On Mon, Sep 12, 2005 at 04:02:02PM +0100, David Reid wrote:
Following the comments from Joe, here is a revised patch that should
work better :-) I've tried to add a sensible comment about why we have
both functions listed.
OpenSSL... isn't up to much isn't really very helpful (or sensible).
If the problem is that X509_ext_print will only handle particular types
of extension and that you can fall back on ASN1_print for extensions
which are simple e.g. string types then say that and cut out the waffle.
OK. Guess spending too long figuring out what did didn't work led me to
a dark place :-)
It removes the nastiness of the len pointer and also converts the
extlist fucntion to simply call into ssl_ext_lookup.
That's pretty nasty, going through all the setup overhead and iterating
through the extension list again for each call. But you miss my point:
the overlap in functionality is a bad thing not an missed opportunity
for refactoring.
OK, then what about the below.
I've changed the log level down to INFO.
DEBUG is the maximum acceptable IMO.
OK. OK. OK. I give in. DEBUG.
david
Index: modules/ssl/ssl_private.h
===
--- modules/ssl/ssl_private.h (revision 279892)
+++ modules/ssl/ssl_private.h (working copy)
@@ -646,10 +646,8 @@
/** Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *,
request_rec *, char *);
-const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const
char *oid);
+apr_array_header_t *ssl_ext_list(apr_pool_t *p, conn_rec *c, int peer,
const char *extension);
-extern apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const
char *oidstr);
-
void ssl_var_log_config_register(apr_pool_t *p);
#define APR_SHM_MAXSIZE (64 * 1024 * 1024)
Index: modules/ssl/ssl_expr_eval.c
===
--- modules/ssl/ssl_expr_eval.c (revision 279892)
+++ modules/ssl/ssl_expr_eval.c (working copy)
@@ -198,63 +198,6 @@
}
}
-#define NUM_OID_ELTS 8 /* start with 8 oid slots, resize when needed */
-
-apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const char *oidstr)
-{
-int count = 0, j;
-X509 *xs = NULL;
-ASN1_OBJECT *oid;
-apr_array_header_t *val_array;
-SSLConnRec *sslconn = myConnConfig(r-connection);
-
-/* trivia */
-if (oidstr == NULL || sslconn == NULL || sslconn-ssl == NULL)
-return NULL;
-
-/* Determine the oid we are looking for */
-if ((oid = OBJ_txt2obj(oidstr, 1)) == NULL) {
-ERR_clear_error();
-return NULL;
-}
-
-/* are there any extensions in the cert? */
-if ((xs = SSL_get_peer_certificate(sslconn-ssl)) == NULL ||
-(count = X509_get_ext_count(xs)) == 0) {
-return NULL;
-}
-
-val_array = apr_array_make(r-pool, NUM_OID_ELTS, sizeof(char *));
-
-/* Loop over all extensions, extract the desired oids */
-for (j = 0; j count; j++) {
-X509_EXTENSION *ext = X509_get_ext(xs, j);
-
-if (OBJ_cmp(ext-object, oid) == 0) {
-BIO *bio = BIO_new(BIO_s_mem());
-
-if (X509V3_EXT_print(bio, ext, 0, 0) == 1) {
-BUF_MEM *buf;
-char **new = apr_array_push(val_array);
-
-BIO_get_mem_ptr(bio, buf);
-
-*new = apr_pstrdup(r-pool, buf-data);
-}
-
-BIO_vfree(bio);
-}
-}
-
-X509_free(xs);
-ERR_clear_error();
-
-if (val_array-nelts == 0)
-return NULL;
-else
-return val_array;
-}
-
static BOOL ssl_expr_eval_oid(request_rec *r, const char *word, const
char *oidstr)
{
int j;
@@ -262,7 +205,7 @@
apr_array_header_t *oid_array;
char **oid_value;
-if (NULL == (oid_array = ssl_extlist_by_oid(r, oidstr))) {
+if (NULL == (oid_array = ssl_ext_list(r-pool, r-connection, 1,
oidstr))) {
return FALSE;
}
Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c (revision 279892)
+++ modules/ssl/ssl_engine_vars.c (working copy)
@@ -62,7 +62,7 @@
{
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
APR_REGISTER_OPTIONAL_FN(ssl_var_lookup);
-APR_REGISTER_OPTIONAL_FN(ssl_ext_lookup);
+APR_REGISTER_OPTIONAL_FN(ssl_ext_list);
return;
}
@@ -660,23 +660,30 @@
return result;
}
-const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer,
- const char *oidnum)
+apr_array_header_t *ssl_ext_list(apr_pool_t *p, conn_rec *c, int peer,
+ const char *extension)
{
SSLConnRec *sslconn = myConnConfig(c);
-SSL *ssl;
+SSL *ssl = NULL;
+apr_array_header_t *array = NULL;
X509 *xs = NULL;
-ASN1_OBJECT *oid;
+ASN1_OBJECT *oid = NULL;
int count = 0, j;
-char *result
Re: [PATCH] ssl_ext_lookup
Joe Orton wrote: On Sat, Sep 10, 2005 at 02:47:17AM +0100, David Reid wrote: Following patch makes some changes to ssl_ext_lookup and changes it's API, hence the post for review. Add some more warnings when things don't go as advertised. I don't think it's appropriate to log warnings (at least at APLOG_WARNING level) from a function like this - only the caller knows whether or not failures require user-visibile warnings or not. OK. I think it makes sense to log them at some level though as otherwise there is no indication what's wrong. When testing these caught me out for a while, hence my additions. Maybe INFO would be a better level to log at? We now allow the known names to be used as extensions to lookup expanding the flexability of the function. Add an index to allow repeated calls to get different values to handle the case when the same extension is present multiple times (there is no restriction how often they can appear I'm aware of). Use of the index seems fine though this is starting to overlap in functionality with the ssl_extlist_by_oid function? Hmm, maybe. Maybe ssl_extlist could just call ssl_ext_lookup? X509V3_EXT_print seems to have trouble printing some simple strings and despite having a default fallback it's still not able to decode them, so we allow a plain return of the data. This could also (concievably) be a small binary section, so we return the length to allow the caller to know how much data is provided. This can probably be improved on. This is similar to what Dirk proposed recently, right? I'll reiterate my concern with this: if OpenSSL cannot return a human-readable char * representation of this extension value then this will instead produce some unusable binary blob? This interface is supposed to return char * strings not binary blobs. Right. I agree with you, but the function we're using fails to cope with even a simple string, so we need another solution. I'll try and come up with an alternative... david
Re: [PATCH] ssl_ext_lookup
David Reid wrote:
Joe Orton wrote:
On Sat, Sep 10, 2005 at 02:47:17AM +0100, David Reid wrote:
Following patch makes some changes to ssl_ext_lookup and changes it's
API, hence the post for review.
Add some more warnings when things don't go as advertised.
I don't think it's appropriate to log warnings (at least at
APLOG_WARNING level) from a function like this - only the caller knows
whether or not failures require user-visibile warnings or not.
OK. I think it makes sense to log them at some level though as otherwise
there is no indication what's wrong. When testing these caught me out
for a while, hence my additions. Maybe INFO would be a better level to
log at?
We now allow the known names to be used as extensions to lookup
expanding the flexability of the function.
Add an index to allow repeated calls to get different values to handle
the case when the same extension is present multiple times (there is no
restriction how often they can appear I'm aware of).
Use of the index seems fine though this is starting to overlap in
functionality with the ssl_extlist_by_oid function?
Hmm, maybe. Maybe ssl_extlist could just call ssl_ext_lookup?
Like this possibly...
Index: modules/ssl/ssl_expr_eval.c
===
--- modules/ssl/ssl_expr_eval.c (revision 279892)
+++ modules/ssl/ssl_expr_eval.c (working copy)
@@ -200,55 +200,24 @@
#define NUM_OID_ELTS 8 /* start with 8 oid slots, resize when needed */
-apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const char *oidstr)
+apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const char *extname)
{
-int count = 0, j;
-X509 *xs = NULL;
-ASN1_OBJECT *oid;
+int count = 0, j, n = 0, len = 0;
apr_array_header_t *val_array;
-SSLConnRec *sslconn = myConnConfig(r-connection);
+const char *val = NULL;
/* trivia */
-if (oidstr == NULL || sslconn == NULL || sslconn-ssl == NULL)
+if (extname == NULL)
return NULL;
-/* Determine the oid we are looking for */
-if ((oid = OBJ_txt2obj(oidstr, 1)) == NULL) {
-ERR_clear_error();
-return NULL;
-}
-
-/* are there any extensions in the cert? */
-if ((xs = SSL_get_peer_certificate(sslconn-ssl)) == NULL ||
-(count = X509_get_ext_count(xs)) == 0) {
-return NULL;
-}
-
val_array = apr_array_make(r-pool, NUM_OID_ELTS, sizeof(char *));
-/* Loop over all extensions, extract the desired oids */
-for (j = 0; j count; j++) {
-X509_EXTENSION *ext = X509_get_ext(xs, j);
-
-if (OBJ_cmp(ext-object, oid) == 0) {
-BIO *bio = BIO_new(BIO_s_mem());
-
-if (X509V3_EXT_print(bio, ext, 0, 0) == 1) {
-BUF_MEM *buf;
-char **new = apr_array_push(val_array);
-
-BIO_get_mem_ptr(bio, buf);
-
-*new = apr_pstrdup(r-pool, buf-data);
-}
-
-BIO_vfree(bio);
-}
+while ((val = ssl_ext_lookup(r-pool, r-connection, 1, extname,
+ n++, len))) {
+char **newentry =apr_array_push(val_array);
+*newentry = (char *)val;
}
-X509_free(xs);
-ERR_clear_error();
-
if (val_array-nelts == 0)
return NULL;
else
david
[PATCH] ssl_ext_lookup #2
Following the comments from Joe, here is a revised patch that should
work better :-) I've tried to add a sensible comment about why we have
both functions listed.
It removes the nastiness of the len pointer and also converts the
extlist fucntion to simply call into ssl_ext_lookup.
I've changed the log level down to INFO.
david
Index: modules/ssl/ssl_private.h
===
--- modules/ssl/ssl_private.h (revision 279892)
+++ modules/ssl/ssl_private.h (working copy)
@@ -646,7 +646,7 @@
/** Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *,
request_rec *, char *);
-const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const
char *oid);
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const
char *extension, int index);
extern apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const
char *oidstr);
Index: modules/ssl/ssl_expr_eval.c
===
--- modules/ssl/ssl_expr_eval.c (revision 279892)
+++ modules/ssl/ssl_expr_eval.c (working copy)
@@ -200,55 +200,24 @@
#define NUM_OID_ELTS 8 /* start with 8 oid slots, resize when needed */
-apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const char *oidstr)
+apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const char *extname)
{
-int count = 0, j;
-X509 *xs = NULL;
-ASN1_OBJECT *oid;
+int count = 0, j, n = 0;
apr_array_header_t *val_array;
-SSLConnRec *sslconn = myConnConfig(r-connection);
+const char *val = NULL;
/* trivia */
-if (oidstr == NULL || sslconn == NULL || sslconn-ssl == NULL)
+if (extname == NULL)
return NULL;
-/* Determine the oid we are looking for */
-if ((oid = OBJ_txt2obj(oidstr, 1)) == NULL) {
-ERR_clear_error();
-return NULL;
-}
-
-/* are there any extensions in the cert? */
-if ((xs = SSL_get_peer_certificate(sslconn-ssl)) == NULL ||
-(count = X509_get_ext_count(xs)) == 0) {
-return NULL;
-}
-
val_array = apr_array_make(r-pool, NUM_OID_ELTS, sizeof(char *));
-/* Loop over all extensions, extract the desired oids */
-for (j = 0; j count; j++) {
-X509_EXTENSION *ext = X509_get_ext(xs, j);
-
-if (OBJ_cmp(ext-object, oid) == 0) {
-BIO *bio = BIO_new(BIO_s_mem());
-
-if (X509V3_EXT_print(bio, ext, 0, 0) == 1) {
-BUF_MEM *buf;
-char **new = apr_array_push(val_array);
-
-BIO_get_mem_ptr(bio, buf);
-
-*new = apr_pstrdup(r-pool, buf-data);
-}
-
-BIO_vfree(bio);
-}
+while ((val = ssl_ext_lookup(r-pool, r-connection, 1,
+ extname, n++))) {
+char **newentry =apr_array_push(val_array);
+*newentry = (char *)val;
}
-X509_free(xs);
-ERR_clear_error();
-
if (val_array-nelts == 0)
return NULL;
else
Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c (revision 279892)
+++ modules/ssl/ssl_engine_vars.c (working copy)
@@ -661,7 +661,7 @@
}
const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer,
- const char *oidnum)
+ const char *extension, int index)
{
SSLConnRec *sslconn = myConnConfig(c);
SSL *ssl;
@@ -669,14 +669,21 @@
ASN1_OBJECT *oid;
int count = 0, j;
char *result = NULL;
-
+
if (!sslconn || !sslconn-ssl) {
return NULL;
}
ssl = sslconn-ssl;
-oid = OBJ_txt2obj(oidnum, 1);
+/* We accept the extension string to be converted as
+ * a long name (nsComment), short name (DN) or
+ * numeric OID (1.2.3.4).
+ */
+oid = OBJ_txt2obj(extension, 0);
if (!oid) {
+ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, c,
+ Failed to create an object for extension '%s',
+ extension);
ERR_clear_error();
return NULL;
}
@@ -692,13 +699,31 @@
X509_EXTENSION *ext = X509_get_ext(xs, j);
if (OBJ_cmp(ext-object, oid) == 0) {
-BIO *bio = BIO_new(BIO_s_mem());
+BIO *bio = NULL;
-if (X509V3_EXT_print(bio, ext, 0, 0) == 1) {
+if (index != -1 --index 0)
+continue;
+
+bio = BIO_new(BIO_s_mem());
+
+/* As Joe keeps pointing out, the object of this function
+ * is to return a string. Sadly the function that openssl
+ * provides (X509V3_EXT_print) isn't up to much and often fails
+ * to provide a string. Thankfully what we want is contained
+ * in ext-value, which is an ASN1_OCTET_STRING. The function
+ * ASN1_STRING_print is able to handle these, so we
[PATCH] ssl_ext_lookup
Following patch makes some changes to ssl_ext_lookup and changes it's
API, hence the post for review.
Add some more warnings when things don't go as advertised.
We now allow the known names to be used as extensions to lookup
expanding the flexability of the function.
Add an index to allow repeated calls to get different values to handle
the case when the same extension is present multiple times (there is no
restriction how often they can appear I'm aware of).
X509V3_EXT_print seems to have trouble printing some simple strings and
despite having a default fallback it's still not able to decode them, so
we allow a plain return of the data. This could also (concievably) be a
small binary section, so we return the length to allow the caller to
know how much data is provided. This can probably be improved on.
With these changes I was able to get mod_authz_svn working correctly
with certificates produced from BaDCA :-)
Comments?
david
Index: modules/ssl/ssl_private.h
===
--- modules/ssl/ssl_private.h (revision 279892)
+++ modules/ssl/ssl_private.h (working copy)
@@ -646,7 +646,7 @@
/** Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *,
request_rec *, char *);
-const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const
char *oid);
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const
char *extension, int index, int *len);
extern apr_array_header_t *ssl_extlist_by_oid(request_rec *r, const
char *oidstr);
Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c (revision 279892)
+++ modules/ssl/ssl_engine_vars.c (working copy)
@@ -661,7 +661,7 @@
}
const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer,
- const char *oidnum)
+ const char *extension, int index, int *len)
{
SSLConnRec *sslconn = myConnConfig(c);
SSL *ssl;
@@ -669,14 +669,24 @@
ASN1_OBJECT *oid;
int count = 0, j;
char *result = NULL;
-
+
+/* Make sure we don't say we're returning any data unless we are */
+*len = 0;
+
if (!sslconn || !sslconn-ssl) {
return NULL;
}
ssl = sslconn-ssl;
-oid = OBJ_txt2obj(oidnum, 1);
+/* We accept the extension string to be converted as
+ * a long name (nsComment), short name (DN) or
+ * numeric OID (1.2.3.4).
+ */
+oid = OBJ_txt2obj(extension, 0);
if (!oid) {
+ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c,
+ Failed to create an OID object for extension '%s',
+ extension);
ERR_clear_error();
return NULL;
}
@@ -692,14 +702,30 @@
X509_EXTENSION *ext = X509_get_ext(xs, j);
if (OBJ_cmp(ext-object, oid) == 0) {
-BIO *bio = BIO_new(BIO_s_mem());
+BIO *bio = NULL;
+
+if (index != -1 --index 0)
+continue;
+
+bio = BIO_new(BIO_s_mem());
if (X509V3_EXT_print(bio, ext, 0, 0) == 1) {
BUF_MEM *buf;
BIO_get_mem_ptr(bio, buf);
result = apr_pstrmemdup(p, buf-data, buf-length);
+*len = buf-length;
}
+/* XXX - Not 100% sure this is really a good idea... */
+else if (ext-value-length 0) {
+result = apr_pmemdup(p, ext-value-data,
ext-value-length);
+*len = ext-value-length;
+/* This is a good idea though :-) */
+} else {
+ap_log_cerror(APLOG_MARK, APLOG_WARNING, 0, c,
+ Found an extension '%s', but failed to
+ create a string from it, extension);
+}
BIO_vfree(bio);
break;
Index: modules/ssl/mod_ssl.h
===
--- modules/ssl/mod_ssl.h (revision 279892)
+++ modules/ssl/mod_ssl.h (working copy)
@@ -37,14 +37,21 @@
char *));
/** The ssl_ext_lookup() optional function retrieves the value of a SSL
- * certificate X.509 extension. The client certificate is used if
- * peer is non-zero; the server certificate is used otherwise. The
- * oidnum parameter specifies the numeric OID (e.g. 1.2.3.4) of the
- * desired extension. The string value of the extension is returned,
- * or NULL on error. */
+ * certificate X.509 extension.
+ * The client certificate is used if peer is non-zero; the server
+ * certificate is used otherwise.
+ * Extension specifies the extensions to use as a string. This can be
+ * one of the known long or short names, or a numeric OID,
+ * e.g. 1.2.3.4, 'nsComment' and 'DN' are all valid.
+ * The index parameter allows for multiple values to be retrieved by
+ * repeated
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
Joe Orton wrote: On Fri, Aug 05, 2005 at 08:00:01PM +0200, Martin Kraemer wrote: On Tue, Aug 02, 2005 at 07:14:10PM +0200, Martin Kraemer wrote: I wanted something like SSLRequire committers in SSLPeerExtList(1.3.6.1.4.1.18060.1); to mean at least one extension with an OID of 1.3.6.1.4.1.18060.1 with a value of 'committers' exists in the client cert. I'll be on vacation next week, and will send in another patch after that. OK, hope you had a good holiday. I wasn't trying to argue about the semantics just to nitpick the naming. Having SSL in the SSLRequire function is redundant, but not in the context of mod_setenvif. So, my preference is: SSLRequire committers in PeerExtList(1.3.6.1.4.1.18060.1); SetEnvIf SSL_PeerExtList(etc) ... +1 on the revised naming. Patch looks OK as well. david
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
Joe Orton wrote: On Mon, Aug 15, 2005 at 02:36:18PM +0100, Joe Orton wrote: I just went to write a test case for the SetEnvIf function, and there seems to be a rather annoying fundamental problem: the match_headers hooks runs too early to be useful for this when doing per-dir client cert negotiation. I can't see any simple way round this, and I don't think this feature should go in 2.2 unless this can be solved. Any ideas? I've not looked at it in detail, so would have to dig through the code. Care to post your test case? david
Re: [vote] Revoke R-T-C [was: svn commit: r219520]
-1
Re: [PATCH] get a pointer to the raw cert from mod_ssl
Joe Orton wrote:
Here's an alternative implementation: does it work for you?
This looks good to me and seems to work as required.
Care to commit it?
david
Index: ssl_private.h
===
--- ssl_private.h (revision 153210)
+++ ssl_private.h (working copy)
@@ -641,6 +641,9 @@
/* Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *, request_rec *, char *);
+
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const char *oid);
+
void ssl_var_log_config_register(apr_pool_t *p);
#define APR_SHM_MAXSIZE (64 * 1024 * 1024)
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 153210)
+++ ssl_engine_vars.c (working copy)
@@ -61,6 +61,7 @@
{
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
APR_REGISTER_OPTIONAL_FN(ssl_var_lookup);
+APR_REGISTER_OPTIONAL_FN(ssl_ext_lookup);
return;
}
@@ -655,6 +656,58 @@
return result;
}
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer,
+ const char *oidnum)
+{
+SSLConnRec *sslconn = myConnConfig(c);
+SSL *ssl = sslconn-ssl;
+X509 *xs = NULL;
+ASN1_OBJECT *oid;
+int count = 0, j;
+char *result = NULL;
+
+oid = OBJ_txt2obj(oidnum, 1);
+if (!oid) {
+ERR_clear_error();
+return NULL;
+}
+
+xs = peer ? SSL_get_peer_certificate(ssl) : SSL_get_certificate(ssl);
+if (xs == NULL) {
+return NULL;
+}
+
+count = X509_get_ext_count(xs);
+
+for (j = 0; j count; j++) {
+X509_EXTENSION *ext = X509_get_ext(xs, j);
+
+if (OBJ_cmp(ext-object, oid) == 0) {
+BIO *bio = BIO_new(BIO_s_mem());
+BUF_MEM *buf;
+
+if (X509V3_EXT_print(bio, ext, 0, 0) != 1) {
+ERR_clear_error();
+BIO_vfree(bio);
+return NULL;
+}
+
+BIO_get_mem_ptr(bio, buf);
+result = apr_pstrmemdup(p, buf-data, buf-length);
+BIO_vfree(bio);
+break;
+}
+}
+
+if (peer) {
+/* only SSL_get_peer_certificate raises the refcount */
+X509_free(xs);
+}
+
+return result;
+}
+
+
/* _
**
** SSL Extension to mod_log_config
Index: mod_ssl.h
===
--- mod_ssl.h (revision 153210)
+++ mod_ssl.h (working copy)
@@ -27,6 +27,16 @@
conn_rec *, request_rec *,
char *));
+/* The ssl_ext_lookup() optional function retrieves the value of a SSL
+ * certificate X.509 extension. The client certificate is used if
+ * peer is non-zero; the server certificate is used otherwise. The
+ * oidnum parameter specifies the numeric OID (e.g. 1.2.3.4) of the
+ * desired extension. The string value of the extension is returned,
+ * or NULL on error. */
+APR_DECLARE_OPTIONAL_FN(const char *, ssl_ext_lookup,
+(apr_pool_t *p, conn_rec *c, int peer,
+ const char *oidnum));
+
/* An optional function which returns non-zero if the given connection
* is using SSL/TLS. */
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *));
Re: [PATCH] get a pointer to the raw cert from mod_ssl
Joe Orton wrote:
Here's an alternative implementation: does it work for you?
I'll try it out tomorrow as time won't permit me to look at it today.
Looks good though.
david
Index: ssl_private.h
===
--- ssl_private.h (revision 153210)
+++ ssl_private.h (working copy)
@@ -641,6 +641,9 @@
/* Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *, request_rec
*, char *);
+
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer, const char
*oid);
+
void ssl_var_log_config_register(apr_pool_t *p);
#define APR_SHM_MAXSIZE (64 * 1024 * 1024)
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 153210)
+++ ssl_engine_vars.c (working copy)
@@ -61,6 +61,7 @@
{
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
APR_REGISTER_OPTIONAL_FN(ssl_var_lookup);
+APR_REGISTER_OPTIONAL_FN(ssl_ext_lookup);
return;
}
@@ -655,6 +656,58 @@
return result;
}
+const char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, int peer,
+ const char *oidnum)
+{
+SSLConnRec *sslconn = myConnConfig(c);
+SSL *ssl = sslconn-ssl;
+X509 *xs = NULL;
+ASN1_OBJECT *oid;
+int count = 0, j;
+char *result = NULL;
+
+oid = OBJ_txt2obj(oidnum, 1);
+if (!oid) {
+ERR_clear_error();
+return NULL;
+}
+
+xs = peer ? SSL_get_peer_certificate(ssl) : SSL_get_certificate(ssl);
+if (xs == NULL) {
+return NULL;
+}
+
+count = X509_get_ext_count(xs);
+
+for (j = 0; j count; j++) {
+X509_EXTENSION *ext = X509_get_ext(xs, j);
+
+if (OBJ_cmp(ext-object, oid) == 0) {
+BIO *bio = BIO_new(BIO_s_mem());
+BUF_MEM *buf;
+
+if (X509V3_EXT_print(bio, ext, 0, 0) != 1) {
+ERR_clear_error();
+BIO_vfree(bio);
+return NULL;
+}
+
+BIO_get_mem_ptr(bio, buf);
+result = apr_pstrmemdup(p, buf-data, buf-length);
+BIO_vfree(bio);
+break;
+}
+}
+
+if (peer) {
+/* only SSL_get_peer_certificate raises the refcount */
+X509_free(xs);
+}
+
+return result;
+}
+
+
/* _
**
** SSL Extension to mod_log_config
Index: mod_ssl.h
===
--- mod_ssl.h (revision 153210)
+++ mod_ssl.h (working copy)
@@ -27,6 +27,16 @@
conn_rec *, request_rec *,
char *));
+/* The ssl_ext_lookup() optional function retrieves the value of a SSL
+ * certificate X.509 extension. The client certificate is used if
+ * peer is non-zero; the server certificate is used otherwise. The
+ * oidnum parameter specifies the numeric OID (e.g. 1.2.3.4) of the
+ * desired extension. The string value of the extension is returned,
+ * or NULL on error. */
+APR_DECLARE_OPTIONAL_FN(const char *, ssl_ext_lookup,
+(apr_pool_t *p, conn_rec *c, int peer,
+ const char *oidnum));
+
/* An optional function which returns non-zero if the given connection
* is using SSL/TLS. */
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *));
Re: [PATCH] set username from certificates at a more appropriate time
William A. Rowe, Jr. wrote:
My only concern ... does this new scope pair up properly if the
user cert has been renegotiated? If so +1
I'm unable to test that here, but maybe if someone has a system where
renegotiation is testable...
david
Bill
At 07:17 PM 2/1/2005, you wrote:
Index: ssl_engine_kernel.c
===
--- ssl_engine_kernel.c (revision 123890)
+++ ssl_engine_kernel.c (working copy)
@@ -798,6 +798,20 @@
}
}
+/* If we're trying to have the user name set from a client
+ * certificate then we need to set it here. This should be safe as
+ * the user name probably isn't important from an auth checking point
+ * of view as the certificate supplied acts in that capacity.
+ * However, if FakeAuth is being used then this isn't the case so
+ * we need to postpone setting the username until later.
+ */
+if ((dc-nOptions SSL_OPT_FAKEBASICAUTH) == 0 dc-szUserName) {
+char *val = ssl_var_lookup(r-pool, r-server, r-connection,
+ r, (char *)dc-szUserName);
+if (val val[0])
+r-user = val;
+}
+
/*
* Else access is granted from our point of view (except vendor
* handlers override). But we have to return DECLINED here instead
@@ -1042,17 +1056,6 @@
}
/*
- * Set r-user if requested
- */
-if (dc-szUserName) {
-val = ssl_var_lookup(r-pool, r-server, r-connection,
- r, (char *)dc-szUserName);
-if (val val[0]) {
-r-user = val;
-}
-}
-
-/*
* Annotate the SSI/CGI environment with standard SSL information
*/
/* the always present HTTPS (=HTTP over SSL) flag! */
[PATCH] get a pointer to the raw cert from mod_ssl
Basically this allows us to gain access to the actual cert structure.
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 123890)
+++ ssl_engine_vars.c (working copy)
@@ -364,6 +364,10 @@
else if (strcEQ(var, CERT)) {
result = ssl_var_lookup_ssl_cert_PEM(p, xs);
}
+else if (strcEQ(var, RAW_CERT)) {
+result = (char *)xs;
+resdup = FALSE;
+}
if (result != NULL resdup)
result = apr_pstrdup(p, result);
Re: [PATCH] get a pointer to the raw cert from mod_ssl
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a char * interface. Exposing the DER representation (e.g.
base64-encoded) through ssl_var_lookup would be better.
The issue is a need to get access to the internals of the structure.
The existing function doesn't meet the requirements, but I'll work up an
alternative patch to add a new function that will meet them.
david
joe
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 123890)
+++ ssl_engine_vars.c (working copy)
@@ -364,6 +364,10 @@
else if (strcEQ(var, CERT)) {
result = ssl_var_lookup_ssl_cert_PEM(p, xs);
}
+else if (strcEQ(var, RAW_CERT)) {
+result = (char *)xs;
+resdup = FALSE;
+}
if (result != NULL resdup)
result = apr_pstrdup(p, result);
Re: [PATCH] get a pointer to the raw cert from mod_ssl
William A. Rowe, Jr. wrote:
At 04:17 AM 2/2/2005, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
Agreed that raw cert isn't that useful, and somewhat frightens
me in the environment table. The PEM or DER formats would be
generally useful. Unpacking the extended X509 attributes
might be even more useful.
Bill
This is the patch that provides me with the functionality I need. It's
generalised to a high degree and provides an easy way to get access to
extension data. It keeps the details hidden within mod_ssl where they
belong.
david
Index: ssl_private.h
===
--- ssl_private.h (revision 123890)
+++ ssl_private.h (working copy)
@@ -633,6 +633,7 @@
/* Variables */
void ssl_var_register(void);
char*ssl_var_lookup(apr_pool_t *, server_rec *, conn_rec *,
request_rec *, char *);
+char*ssl_ext_lookup(apr_pool_t *, conn_rec *, char *, char *);
void ssl_var_log_config_register(apr_pool_t *p);
#define APR_SHM_MAXSIZE (64 * 1024 * 1024)
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 123890)
+++ ssl_engine_vars.c (working copy)
@@ -60,6 +60,7 @@
{
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
APR_REGISTER_OPTIONAL_FN(ssl_var_lookup);
+APR_REGISTER_OPTIONAL_FN(ssl_ext_lookup);
return;
}
@@ -654,6 +655,68 @@
return result;
}
+/* This function must remain safe to use for a non-SSL connection.
+ * This function is essentially the same as ssl_var_lookup but it looks
ONLY
+ * in the X509_EXTENSION structures. It looks for a matching OID and
(optionally)
+ * a value to match.
+ */
+char *ssl_ext_lookup(apr_pool_t *p, conn_rec *c, char *oid, char *var)
+{
+SSLConnRec *sslconn = myConnConfig(c);
+char *result = NULL;
+SSL *ssl = sslconn-ssl;
+X509 *xs = NULL;
+int count = 0, j;
+size_t oidlen, varlen = 0;
+
+if (!oid)
+return result;
+
+oidlen = strlen(oid);
+if (var)
+varlen = strlen(var);
+
+/*
+ * When no pool is given try to find one
+ */
+if (p == NULL) {
+if (c != NULL)
+p = c-pool;
+}
+if (!p)
+return result;
+
+/* We ONLY operate on peer certificates */
+if (! (xs = SSL_get_peer_certificate(ssl)))
+return result;
+
+if ((count = X509_get_ext_count(xs)) == 0)
+return result;
+
+for (j = 0; j count; j++) {
+X509_EXTENSION *ext = X509_get_ext(xs, j);
+char *this_oid = alloca(oidlen + 1);
+if (OBJ_obj2txt(this_oid, oidlen + 1, ext-object, 1) == oidlen
+strncmp(this_oid, oid, oidlen) == 0) {
+/* We have found a matching OID.
+ * If we have been asked to match a value, then we check it
here,
+ * if we've just been asked to find an instance of the OID
+ * then we simply return the value.
+ */
+char *str = ASN1_STRING_data((ASN1_STRING *)ext-value);
+if (var) {
+if (strncmp(str, var, varlen) == 0)
+result = apr_pstrdup(p, str);
+} else
+result = apr_pstrdup(p, str);
+
+if (result)
+break;
+}
+}
+return result;
+}
+
/* _
**
** SSL Extension to mod_log_config
Index: mod_ssl.h
===
--- mod_ssl.h (revision 123890)
+++ mod_ssl.h (working copy)
@@ -26,6 +26,11 @@
conn_rec *, request_rec *,
char *));
+/* The ssl_ext_lookup() optional function retrieves SSL environment
+ * variables. */
+APR_DECLARE_OPTIONAL_FN(char *, ssl_ext_lookup,
+(apr_pool_t *, conn_rec *, char *, char *));
+
/* An optional function which returns non-zero if the given connection
* is using SSL/TLS. */
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *));
[PATCH] set username from certificates at a more appropriate time
Index: ssl_engine_kernel.c
===
--- ssl_engine_kernel.c (revision 123890)
+++ ssl_engine_kernel.c (working copy)
@@ -798,6 +798,20 @@
}
}
+/* If we're trying to have the user name set from a client
+ * certificate then we need to set it here. This should be safe as
+ * the user name probably isn't important from an auth checking point
+ * of view as the certificate supplied acts in that capacity.
+ * However, if FakeAuth is being used then this isn't the case so
+ * we need to postpone setting the username until later.
+ */
+if ((dc-nOptions SSL_OPT_FAKEBASICAUTH) == 0 dc-szUserName) {
+char *val = ssl_var_lookup(r-pool, r-server, r-connection,
+ r, (char *)dc-szUserName);
+if (val val[0])
+r-user = val;
+}
+
/*
* Else access is granted from our point of view (except vendor
* handlers override). But we have to return DECLINED here instead
@@ -1042,17 +1056,6 @@
}
/*
- * Set r-user if requested
- */
-if (dc-szUserName) {
-val = ssl_var_lookup(r-pool, r-server, r-connection,
- r, (char *)dc-szUserName);
-if (val val[0]) {
-r-user = val;
-}
-}
-
-/*
* Annotate the SSI/CGI environment with standard SSL information
*/
/* the always present HTTPS (=HTTP over SSL) flag! */
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. I agree with the sentiment but this list is httpd specific - is this *really* the right place to debate having a hackathon? As Paul said, I meant only for this hackathon to be focused on httpd. If for example, we had an ASF-wide hackathon not held during ApacheCon, it'll just increase the 'distraction' on those that participate in multiple groups. Well, the plans that were discussed at the Con were for that very type of event, NOT a project specific event along the lines you're discussing. During ApacheCon, I was frustrated that I kept getting pulled off to do infra@ or prc@ stuff instead of being able to focus solely on httpd stuff. (Sander and Greg kept getting pulled out for board stuff as well.) That's understandable. So, I'm very, very strongly in favor of having an httpd-only hackathon. Keep it small and focused to minimize distractions. -- justin Then may I'd suggest you not use the term hackathon :-) Organising an httpd developer get together is an excellent idea, but the hackathon is slowly turning into a brand and a series of events with all the baggage that goes with them... I'm hoping to arrange a hackathon in London sometime around the end of Feb/start of Mar 2005 (with hopefully another later in the year somewhere else in the UK). As it's a hackathon it'll be open to all and won't just be for one project or another. I realise people will think I'm splitting hairs, but as we move forwards I think these distinctions will become more and more important. Also I believe that there will be definately be a 2 day hackthon prior to ApacheCon europe. david
Re: Hackathon during Q1 2005?
Justin Erenkrantz wrote: During ApacheCon, a number of us had talked about holding more frequent face-to-face meetings (or summits or whatever). Fred is willing to find a place for us at Apple with space and 'net access. Fred's suggested around the week of February 7th, 2005. That would work for me as well. I agree with the sentiment but this list is httpd specific - is this *really* the right place to debate having a hackathon? So, how many people would be interested, willing, and able to make it? I might actually be around, but regardless this isn't the correct venue to discuss having a hackathon event. david
Re: [PROPOSAL] cgi_exec_info_t: detached addrspace fieldscombined
To replace the addrspace field that was added in the cgi_exec_info_t struct in mod_cgi.h I will like to propose extending the use of the detached (apr_int32_t) field in cgi_exec_info_t and apr_procattr_t structs. Currently that field is set to 0 by default and 1 if the process to be created will be a detached one. What I will like to do to is to add an address space option to set the second bit of that field in order to flag the new process to load or not in a new address space. The detached field in cgi_exec_info_t is set to 0 for all platforms and is used only in mod_netware and mod_win32. The changes will need to be back ported in order for NetWare to work after log.c r r1.145 is back ported. Follow a partial patch, I will certainly like to have suggestions: Thank you, I'm not even going to look at this for 1.0 :-( Plan is to roll rc2 on Sunday for a hopeful release on Wed next week. :-) david
Re: cvs commit: httpd-2.0 STATUS
The entire contents of mod_ssl.h just cannot be considered a public API, that's too much, even the config structures are in there. The only thing that's usable from other modules is the optional hook, and in reality that declaration just gets cut'n'pasted anyway (even by third-party modules I've seen). Agreed. Without the proper API wrapper (AP_DECLARE) a function may fail to be usable multiplatform anyway. Anything without API wrappers should be considered implementation details. We could issue an RFC on this issue with next stable release, stating how module authors can determine whether a callable function in an Apache header file is considered an API, and explaining our need to modify implementation details as necessary to keep the code base maintainable as we make fixes and enhancements. Any screaming could hopefully be converted into clear requests for certain interfaces to be considered APIs. Sounds like a good plan. +1 david
Re: Forensic Logging
Colm MacCarthaigh wrote: On Mon, Dec 29, 2003 at 01:39:28PM +, Ben Laurie wrote: So, I've written a forensic logging module. What this does is log the request as soon as all the headers have been read, then log again when its complete. Any request that doesn't complete should be viewed with great suspicion! Cool, extremely useful in a lot of circumstances. Just one or two questions though. Is next_id deliberately random? It doesn't seem to get initialised anywhere, though that may be a feature. Static variables are initialised to zero. That's not true on all platforms, sadly :( david
Re: Apache MPMs comparing new fds with FD_SETSIZE, APR's ability to wait for i/o on socket
Currently when Apache httpd accepts a new connection via APR, it compares the fd with FD_SETSIZE and bombs if fd = FD_SETSIZE. The limited value of this check is on platforms such as OS X 10.3 with no poll(), where APR has to use select(). Unfortunately, use 1K threads with worker MPM on Solaris or some other platform with relatively small *default* FD_SETSIZE and you'll start hitting meaningless FD_SETSIZE errors before you get the 1K threads busy talking to clients. (APR doesn't use select() on Solaris anyway, so the FD_SETSIZE check is not helpful.) For APR 1.0, I think it would be better for APR to handle this to the greatest extent so that APR apps don't have to worry about whether or not APR uses select(). This seems entirely sensible :) david
Re: [PATCH] Apache as a transparent proxy
Are you willing to break upgrades for people who currently use fall-back virtual hosts in combination with a forward proxy? Are there any people doing this? By that I mean combining the services of Apache both as a webserver and as a forward proxy at the same time? (I'm not a proxy expert, so perhaps there is a technical reason people can't do this now. But according to the documentation, I see no reason to believe that.) Perhaps a safer solution would be to apply this behaviour to v2.1, but not to v2.0 - as v2.0 to v2.1 is a major upgrade, it seems safe to make such a behavior change there. Thoughts? Seems like a reasonable solution to me :) david
Re: Time for 2.2?
Seems like a plan. Do we then migrate from 2.0 to 2.2 for our *stable* tree? Some extra clarification might be nice... david - Original Message - From: Justin Erenkrantz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 5:48 PM Subject: Time for 2.2? Looking at nd's recent mod_rewrite and mod_include changes including the aaa rewrite (and some other changes and new modules that just weren't backported), I'm starting to think this is about the 'right feel' for a 2.2 release. 2.1 has essentially been open since last September. So, I think we should start producing 2.1 unstable releases with a goal of producing a stable 2.2 release in a few months. The one issue I'd like resolved before starting a 2.1 release cycle is figuring out if we can axe ap_*_client_block (as this is a major API change). I think Sander's mentioned something about changing how authorization hooks are called, but I don't know if he's prepared to do it 'soon.' Thoughts? -- justin
Re: [PATCH][1.3] Segfault in mod_proxy
Let's release 1.3.28... david - Original Message - From: Thom May [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 1:49 PM Subject: Re: [PATCH][1.3] Segfault in mod_proxy * Jim Jagielski ([EMAIL PROTECTED]) wrote : Thom May wrote: Hi folks, Hmmm... I wonder if we should hold off on 1.3.28 then. I'm leaning towards releasing 1.3.28 as-is, and us placing this in patches/ (and of course, being committed to 1.3.29-dev)... Any objections? I don't see that we should hold off 1.3.28, but maybe bring up the timescale for .29 a bit afterwards. So yes, +1. (Sorry for bringing this up today, but we litterally only found and fixed it late last night) Cheers -Thom
Fw: Spam postings via Apache to postfix on the same host
Fun. - Original Message - From: Info iNetD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 05, 2003 7:34 PM Subject: Spam postings via Apache to postfix on the same host Hello, Hello, I have found out on two different machines that somebody is posting spam to postfix via a certain string to the apache webserver. All entries in the apache logs look like: 203.98.177.86 - - [24/Jun/2003:12:33:27 +0200] POST http://xx.xx.xx.xx:25/ HTTP/1.1 200 208 (like can be wrapped) where xx.xx.xx.xx is the local machine ip's. All spam is send and delivered (until I stopped the webserver of course). The machine's ip is not in the mynetworks list, localhost is however. My postfix version is: 2.0.10-20030521 It could also be a configuration problem of Apache of course, I am not sure where to look. Any ideas are welcome. Thanks in advance. Arnold. -- Info iNetD [EMAIL PROTECTED]
Re: Fw: Spam postings via Apache to postfix on the same host
I figured as much that's why I cross-posted here from the postfix list :) I'm +1 on removing the default proxy stuff as well. If not then we should change it to be secure by default if that's possible. Hopefully the person concerned found all the interest helpful? david - Original Message - From: Joshua Slive [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 05, 2003 7:44 PM Subject: Re: Fw: Spam postings via Apache to postfix on the same host On Sat, 5 Jul 2003, David Reid wrote: 203.98.177.86 - - [24/Jun/2003:12:33:27 +0200] POST http://xx.xx.xx.xx:25/ HTTP/1.1 200 208 Yes, it's an apache configuration problem. They set ProxyRequests On without properly securing their proxy server. This means they can be abused for tons of purposes, one of which is spam. One possible thing we could do is simply remove the sample proxy config from our default httpd.conf. These samples make it too easy for people to activate a proxy without securing it properly. Joshua.
Re: [PATCH] remove hardcoding of suexec log location
Maybe we should have another directive for the suexec log? But I agree it shouldn't be hardcoded. david - Original Message - From: Thom May [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 31, 2002 11:39 AM Subject: [PATCH] remove hardcoding of suexec log location This is to fix PR 15713 suexec-logfile has hardcoded default instead of being placed in --logfiledir I'm not sure it's right, though, since I'm not sure of the status of suexec on win32/other places where ap_config_layout.h isn't available. -Thom Index: support/suexec.h === RCS file: /home/cvspublic/httpd-2.0/support/suexec.h,v retrieving revision 1.7 diff -u -u -r1.7 suexec.h --- support/suexec.h 27 Sep 2002 23:53:04 - 1.7 +++ support/suexec.h 30 Dec 2002 12:10:17 - @@ -62,6 +62,12 @@ #define _SUEXEC_H /* + * Include ap_config_layout so we can work out where the default htdocsdir + * and logsdir are. + */ +#include ap_config_layout.h + +/* * HTTPD_USER -- Define as the username under which Apache normally * runs. This is the only user allowed to execute * this program. @@ -117,7 +123,7 @@ * debugging purposes. */ #ifndef AP_LOG_EXEC -#define AP_LOG_EXEC /usr/local/apache2/logs/cgi.log /* Need me? */ +#define AP_LOG_EXEC DEFAULT_EXP_LOGFILEDIR /suexec_log /* Need me? */ #endif /* @@ -126,7 +132,7 @@ * that can be used for suEXEC behavior. */ #ifndef AP_DOC_ROOT -#define AP_DOC_ROOT /usr/local/apache2/htdocs +#define AP_DOC_ROOT DEFAULT_EXP_HTDOCSDIR #endif /*
Re: Can't compile HEAD on Linux
Yep, it was cured by reverting Fred's changes to server/Makefile.in (sorry Fred). Upgrading awk didn't help on beos. Apart from that changes to htpasswd mean it's broken on a non-unix box due to using P_tmpdir. This is something that APR should fix but it's currently involved in a competition to see how far up it's own butt it can stick it's head... david - Original Message - From: Thom May [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 09, 2002 6:46 PM Subject: Re: Can't compile HEAD on Linux * Wilfredo S?nchez ([EMAIL PROTECTED]) wrote : Yeah, do you still have the log from when it failed? I noticed you took it off the URL you posted. Sander, you ran into the same build failures? See Eric Gillespie's posts to dev@apr; David was seeing the same thing with BeOS; I could reproduce with GNU awk 3.0.3 but 3.1.3 fixed the problem. Basically, there were two problems: find -maxdepth is a GNUism; and *something* in your changes was breaking the generation of exports.c. If anyone wants an account on a NetBSD box to play with this, drop me a mail with an ssh key. Cheers, -Thom, apologising for being vague but being short on time.
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
As Jeff suggested a while back do we know which versions of the linux kernel
are affected by this problem? If so we can probably have the flag
automagically set.
Otherwise this looks OK to me.
david
- Original Message -
From: Colm MacCárthaigh [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, December 04, 2002 12:30 PM
Subject: Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Wed, Dec 04, 2002 at 12:25:49PM +, Colm MacCárthaigh wrote:
My tests (and patch) were based on apr and apr-util from CVS ,
with the 2.0.43 codebase, because CVS seems broken right now.
stupid pre-test patch, here's the real one:
Index: configure.in
===
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.506
diff -u -r1.506 configure.in
--- configure.in 2 Dec 2002 16:07:09 - 1.506
+++ configure.in 4 Dec 2002 12:29:41 -
@@ -1770,6 +1770,16 @@
echo ${nl}Checking for IPv6 Networking support...
dnl Start of checking for IPv6 support...
+use_ipv6_tcp_cork=1
+AC_ARG_ENABLE(ipv6-tcp-cork,
+ [ --disable-ipv6-tcp-cork Disable TCP_CORK with IPv6.],
+ [ if test $enableval = no; then
+use_ipv6_tcp_cork=0
+ fi ],
+ [ use_ipv6_tcp_cork=1 ] )
+
+AC_SUBST(use_ipv6_tcp_cork)
+
AC_ARG_ENABLE(ipv6,
[ --disable-ipv6 Disable IPv6 support in APR.],
[ if test $enableval = no; then
Index: include/apr.h.in
===
RCS file: /home/cvspublic/apr/include/apr.h.in,v
retrieving revision 1.117
diff -u -r1.117 apr.h.in
--- include/apr.h.in 22 Oct 2002 12:37:40 - 1.117
+++ include/apr.h.in 4 Dec 2002 12:29:41 -
@@ -171,6 +171,11 @@
*/
#define APR_TCP_NOPUSH_FLAG @apr_tcp_nopush_flag@
+/* Should we use corked TCP with IPv6 ? (this seems to be broken on
+ * linux
+ */
+#define APR_USE_IPV6_TCP_CORK @use_ipv6_tcp_cork@
+
/* Is the TCP_NODELAY socket option inherited from listening sockets?
*/
#define APR_TCP_NODELAY_INHERITED @tcp_nodelay_inherited@
Index: network_io/unix/sockopt.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockopt.c,v
retrieving revision 1.63
diff -u -r1.63 sockopt.c
--- network_io/unix/sockopt.c 20 Nov 2002 03:50:21 - 1.63
+++ network_io/unix/sockopt.c 4 Dec 2002 12:29:42 -
@@ -259,7 +259,12 @@
return APR_ENOTIMPL;
#endif
}
+#if APR_USE_IPV6_TCP_CORK
if (opt APR_TCP_NOPUSH) {
+#else
+if (opt APR_TCP_NOPUSH sock-remote_addr-sa.sin.sin_family !=
APR_INET6) {
+#endif
+
#if APR_TCP_NOPUSH_FLAG
if (apr_is_option_set(sock-netmask, APR_TCP_NOPUSH) != on) {
int optlevel = IPPROTO_TCP;
--
[EMAIL PROTECTED]PubKey: [EMAIL PROTECTED]
Web: http://devnull.redbrick.dcu.ie/
Re: compromise on RTC vs. CTR for stable???
Sounds like a reasonable compromise. I'm not a huge fan of using STATUS for these things, but it's as good a place as anywhere else. david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 02, 2002 1:44 PM Subject: compromise on RTC vs. CTR for stable??? Since the relatively few people who voted left us at an impasse on this, it seems appropriate to try to find a compromise. (I've been told before that something other than normal RTC-with-3-+1 vs. CTR isn't the Apache way or something to that effect, but I don't see that such concerns should stand in the way of each side giving up some ground.) How about using this for the stable tree? To merge something from dev to stable (or fix it in stable if the fix is specific to stable): either three committers (including submitter) state their approval or four days elapses with no objections An entry in the STATUS file for that period of time will be necessary to satisfy the second criteria. Such an entry will often be helpful for satisfying the first criteria as well. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
In the interest of tying up loose ends, I'm still concerned with your observation that --disable-sendfile didn't do the right thing... did you make distclean before re-configuring? The problem there was that --disable-sendfile isnt an option configure knows anything about, the right one is --without-sendfile, which does work, and does fix the problem. :-) However, that will disable sendfile on IPv4 as well won't it? Can you just confirm that it does for both v4 and v6? Thanks. david
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Wed, Dec 04, 2002 at 02:29:29PM -, David Reid wrote: In the interest of tying up loose ends, I'm still concerned with your observation that --disable-sendfile didn't do the right thing... did you make distclean before re-configuring? The problem there was that --disable-sendfile isnt an option configure knows anything about, the right one is --without-sendfile, which does work, and does fix the problem. :-) However, that will disable sendfile on IPv4 as well won't it? Can you just confirm that it does for both v4 and v6? Thanks. yep, --without-sendfile completely disables sendfile , so IPv4 won't try to use it, or TCP_CORK, which is a bit of a loss (for IPv4). The patch will just disable TCP_CORK for IPv6, but continue to use sendfile in both cases. Thanks, in that case +1 for the patch :) david
Re: Linux + TCP_CORK + IPv6 = Broken
Linux (2.4.18 and 2.4.19, for me anyway) with apache versions 2.0.40 to 2.0.43 (that I've tested anyways) is broken with TCP_CORK and IPv6. Bizarrely v6 requests will work the first few times and then start failing, typically you just wont get a response from the server. Though strace shows that it did try to send one. Anyway, disabling TCP_CORK fixes it and it works fine again, useful info for anyone running IPv6, because believe me, it took me all morning to figure out what the hell was going on. Might be worth adding a --disable-tcp-cork option to ./configure for convienence :-) That seems like a good idea if it causes problems... david
Re: 2.1 Fallout; httpd v.s. httpd-2.0
Why do this? Do people really feel a strong enough need to scratch an itch that they're willing to cause such grief? What will this gain us? I can't see any big wins from this - only a lot of effort being expended to get us where we are. If we really, really need 2.1 then start a new repository. Call it anything you like, with/without numbers, but don't change an active repository name simply to satisfy an itch we don't all share or even recognise. -1 to the move. +1 to a new repository. david Although I don't have the karma, I'll take the fallout and flak for coming up with the idea (although not the initial objection) that was raised for changing the repository's name from httpd-2.0 to httpd. A couple folks have suggested we shouldn't use a branch for various reasons. I mildly to strongly disagree with the reasons given. Centralizing the history into a single repository is massive goodness. Yes, with cvs this isn't an optimal and performant solution, but it has worked just fine for Tomcat. We aren't speaking of multiple oodles of branches, only one every blue moon (every six months to a year, perhaps.) If and when we convert to SVN, and the branch conversion bug is addressed and long gone, the entire history of the project since 2.0.0 will be available in a single place for all to review. That, I believe, is goodness. So, I then realized how badly this f*s things up without advance notice and consideration to all the places (cvs commit messages, viewcvs, et al) and folks (with active checkouts) that need to prepare for the change. So thank you Roy for flipping the switch back to 'normal' operations. So, proceeding on the idea that 2.X lives in a single repository, (which was voted for a month with absolute concensus) where can we go from here, and how do we have to prepare? Obviously, infrastructure needs to be involved, including apmail, viewcvs, and other things I don't recognize at the moment. End users need time to update their cvs checkouts to the new canonical location. Lets say 45 days from the beginning of the changeover, with a headline in the top level httpd.apache.org index.html and details in /dev/. So when we begin the changeover, how do we avoid becoming hopelessly confused? I believe we begin with warning commiters about 15 days before, then 5, then 2, then 1 day before the change. On that day, httpd-2.0 becomes httpd. All cvs apmail and viewcvs resources are redirected at that time. httpd-2.0 becomes a module alias, WITH NO COMMIT PRIVILAGES for any users. This way we don't have some scattershot history of httpd-2.0 and httpd commits. Now, only committers were affected by that change, because everyone can still check out httpd-2.0. Now over the next month and a half, we encourage folks who follow the news that the repository name has changed. We encourage them to change over in a short time, just as our friends in Europe had to exchange their money not so long ago. Finally (before 2.2, certainly) this change becomes effective. The alias to httpd-2.0 cvs repository disappears. Users scrambling to find out what broke should be greeted again at httpd.apache.org/ and /dev/ to news of how to fix it. Ken's change for htdocs was really a pita because existing checkouts were simply broken. This isn't the case for this schema. You update when you need to commit (and the system's informed you you cannot commit.) Planned chaos rather than unanticipated chaos. Folks, any other observations besides apmail, viewcvs and the other aspects we must consider before we contemplate a rename? Bill
Re: 2.1 Fallout; httpd v.s. httpd-2.0
If you are looking at 2.1 being as different from 2.0 as 1.3 and 2.0 are, then perhaps a branch isn't the best idea. But if you are looking at having that many differences before 2.0 has even had a chance to stablize, I think you are asking for trouble and how to manage the CVS repository would be the least of the worries... Hmm, a nice summary of my own feelings and concerns. :) david
Re: 2.1 Fallout; httpd v.s. httpd-2.0
Reading emails like this remind me of the days when I really wonder why anyone would ever want to participate in the project... sigh... david At 08:30 AM 11/25/2002, Jim Jagielski wrote: David Reid wrote: [Will recalls Marc Slemco stating:] If you are looking at 2.1 being as different from 2.0 as 1.3 and 2.0 are, then perhaps a branch isn't the best idea. But if you are looking at having that many differences before 2.0 has even had a chance to stablize, I think you are asking for trouble and how to manage the CVS repository would be the least of the worries... Hmm, a nice summary of my own feelings and concerns. :) And mine as well (and a concern I had since the topic was 1st mentioned/ suggested many moons ago). The 2.1 branch makes sens iff the intent is to place 2.0 in API and feature freeze and work on stabilizing and tuning the code, not that we're bored with 2.0 and want to work on the next cool verson and all this crud about keeping 2.0 stable and robust is really slowing down my creative juices ;) Not that anyone is saying, or has said that. Nope. Folks have asked that 2.0 stop being a sandbox for those next cool features and that we get 2.0 code working. However, folks want to proceed with the next cool features. Why ask them to quit it? Since most of the active committers, (first in terms of applying their own and others' bug fixes, and secondly still participants in the project) expressed content with having a separate stable tree and a sandbox for continued work, and a vote was conducted for a month with not so much as a -0, I won't be too frustrated when folks start rehashing the decision for the next year. You may as well also start venting over how poor the old 1.3 is doing (but don't go fixing it, that would take away all the fun of griping about it :-) Which takes us to the question raised by the three of you. It's Apache. You scratch Your own itch. If that's maintenance (as Jeff, myself, and many others including yourselves keep persisting in) then that's cool. If that itch is new development, such as auth refactoring, async overhaul or factoring out the filesystem, then that's cool too. Participate how you like; that's the point of *this* Apache project. Even the backseat drivers are welcome here :-) Bill
Re: cvs commit: httpd-2.0 STATUS
Language can be a terrible thing... If Jim feels like this then we should all be pausing for thought. Aaron, calling for a vote will not accomplish anything with feelings having been so inflamed. In fact there seems to have been a rash of this sort of outburst and ensuing chaos recently. One of the catchphrases at the 'Con among a group of us became Can't we all just get along... - maybe it's also valid here? david [EMAIL PROTECTED] wrote: jim 2002/11/25 12:54:59 Modified:.Tag: APACHE_2_0_BRANCH STATUS Log: It appears that I am unworthy to have an opinion... On what grounds? I would assume that if you aren't worthy then neither am I, so I would need to participate in a similar exorcism of opinions... I assumed all committers were worthy. -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
Re: karma and cvs commit messages
Agreed 100% This whole episode stinks... david --On Saturday, November 23, 2002 3:32 PM -0800 Roy T. Fielding [EMAIL PROTECTED] wrote: Since we renamed the repository to httpd from httpd-2.0 (there is a symlink for now), the CVSROOT/avail file doesn't match the repository name, and therefore I can't commit. Can we fix that so I can commit to the new httpd repository directly? Why the heck was that done? Too many things get screwed over when you change a module name in cvs. Yeah, exactly. We had zero discussion on this change. And, it's a bad change, IMHO. People shouldn't be making such drastic changes without some sort of discussion! IMHO, httpd-2.0 must always be the definitive repository for Apache HTTP Server 2.0. If we physically split the 2.1/(2.2/3.0) repositories, we can then change the name (please discuss this first). Note that 2.0 shouldn't be housed there, since it once authoritatively lived in httpd-2.0. ISTR the big snafu when Ken 'renamed' the httpd-docs repository. That should have warned us that such moves are a horrible idea. I know Subversion has lots of drawbacks (I know of at least 2 committers who will veto it outright), but remember that branches in CVS kill performance (really due to the now anachronistic RCS format and how it stores branches). It's going to be a PITA performance-wise if we have a long-lived CVS repository. So, I think there is a strong benefit to creating httpd-2.1 and then httpd-2.2 and so on. I'm afraid by the time that we hit httpd 2.9 (say), we're going to be in a world of hurt on the 'stable' branches due to CVS's inability to scale with active branches. -- justin
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Given the recent behavior of some I'm actually now in favour of C-T-R for any stable tree... Treat adults as adults until they prove they can't be so treated. +1 for C_T_R for stable branches david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 2:20 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Bill Stoddard [EMAIL PROTECTED] writes: I think that R-T-C is the most likely way we'll get good reviews of code moved to the stable tree. Jeff is speaking from his experience with 2.0 development and I would have to agree with him in this regard. I believe that our experiences with 2.0 development (and recent 1.3 maintenance) are indicative of what is going to happen with 2.0-stable, or at least much more so than any experiences from several years ago. Obviously the interpretation of that experience is subject to debate :) --/-- Everybody has their own vision and we have to find the greatest commonality to decide how to work. Here are some aspects of mine: . 1.3 maintenance needs to be a bit healthier... more involvement of people when somebody wants to fix something... right now it can be hard to get anybody to give a shit when you want to fix something... . 2.0-stable maintenance along the lines of 1.3, but I think that fixing things in 2.0-stable is much more important than fixing things in 1.3.. 2.0-stable maintenance right now is for the relatively few who try 2.x before the hoped-for avalanche, and fixing their problems is going to prevent a world of hurt later on (1.3 clearly works well-enough for almost anybody) . 2.1... just like what has happened with 2.0 thus far... This has nothing to do with C-T-R vs. R-T-C; that is just a choice of which crude tool can best be used to achieve a goal. One of the useful properties of R-T-C is that if you don't have enough interest to keep a tree maintained in a healthy manner it becomes painfully obvious almost immediately. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: karma and cvs commit messages
Agreed. Didn't know we were in the business of screwing ourselves like this... david Since we renamed the repository to httpd from httpd-2.0 (there is a symlink for now), the CVSROOT/avail file doesn't match the repository name, and therefore I can't commit. Can we fix that so I can commit to the new httpd repository directly? Why the heck was that done? Too many things get screwed over when you change a module name in cvs. -1 -- I am reverting that change to cvs. Don't screw with this stuff without a clear plan in STATUS, and notify apmail and cvsadmin before screwing with the filesystem. It would have been far more sensible not to branch 2.0 and instead create a new module that doesn't suffer from legacy versions. Roy
Re: binbuild.sh favors GNU tar
+1 from me. david - Original Message - From: Wilfredo Sánchez [EMAIL PROTECTED] To: Apache HTTPD Developers [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 8:18 PM Subject: binbuild.sh favors GNU tar binbuild.sh seems to prefer gtar to tar for archiving. This doesn't actually happen on Mac OS X because on Darwin, it's 'gnutar', not 'gtar'. This is trivial to fix, except that I'd rather not use GNU tar if I don't have to. The reason being that GNU tar generates non-POSIX-compliant tar archives, which when unpacked with POSIX tar potentially gives you a bogus @LongLink directory. I'd rather use a POSIX tar program which both POSIX tar and GNU tar can unpack properly. The only drawback there is if we have really long path names, POSIX tar craps out where GNU tar doesn't. I don't think we have really long path names, though. So does anyone object if I un-favor GNU tar? Looks like the real reason we favor it is to use the -z option instead of having to run gzip after the fact. Running gzip in a pipe chain would do as well, though. -wsv
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Whoops...not enough sleep :) That should read as R-T-C not C-T-R... I also tend to think this should be applied to the 1.3 tree. david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 8:36 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Given the recent behavior of some I'm actually now in favour of C-T-R for any stable tree... Treat adults as adults until they prove they can't be so treated. +1 for C_T_R for stable branches david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 24, 2002 2:20 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Bill Stoddard [EMAIL PROTECTED] writes: I think that R-T-C is the most likely way we'll get good reviews of code moved to the stable tree. Jeff is speaking from his experience with 2.0 development and I would have to agree with him in this regard. I believe that our experiences with 2.0 development (and recent 1.3 maintenance) are indicative of what is going to happen with 2.0-stable, or at least much more so than any experiences from several years ago. Obviously the interpretation of that experience is subject to debate :) --/-- Everybody has their own vision and we have to find the greatest commonality to decide how to work. Here are some aspects of mine: . 1.3 maintenance needs to be a bit healthier... more involvement of people when somebody wants to fix something... right now it can be hard to get anybody to give a shit when you want to fix something... . 2.0-stable maintenance along the lines of 1.3, but I think that fixing things in 2.0-stable is much more important than fixing things in 1.3.. 2.0-stable maintenance right now is for the relatively few who try 2.x before the hoped-for avalanche, and fixing their problems is going to prevent a world of hurt later on (1.3 clearly works well-enough for almost anybody) . 2.1... just like what has happened with 2.0 thus far... This has nothing to do with C-T-R vs. R-T-C; that is just a choice of which crude tool can best be used to achieve a goal. One of the useful properties of R-T-C is that if you don't have enough interest to keep a tree maintained in a healthy manner it becomes painfully obvious almost immediately. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: alloca() issue on tru64
Do we agree that once 2.0.41 is launched it should be converted to a configure-time check for alloca.h, with the code changed to include the header if it exists, irrespective of Tru64? +1 david
Re: IPv6 capability and name lookup cost
Looks fine to me. What will the order of the returned matches be for All? IPv4 then IPv6 would be my suggestion which we should be able to do with the changes you're talking about I'd guess. david Jeff Trawick [EMAIL PROTECTED] writes: A useful performance improvement can be achieved by allowing the administrator to select the following algorithm: lookup IPv4 if at least one IPv4 address was found, we're done lookup IPv6 Getting more specific, I envision a directive that works like this: NameLookups All|IPv4Okay|IPv6Okay All: current behavior -- tell resolver to find everything IPv4Okay: try IPv4 first, don't look for IPv6 unless no IPv4 addresses found note: if the host is specified in the form of an IPv6 numeric address string, APR will do the right thing IPv6Okay: try IPv6 first, don't look for IPv4 unless no IPv6 addresses found note: if the host is specified in the form of an IPv4 numeric address string, APR will do the right thing (potentially we could add something like this in the future, though I don't think that is necessary now since it is an optimization for an error path: IPv4Only: only look for IPv4 addresses IPv6Only: only look for IPv6 addresses ) I guess core should export the information via a function like ap_get_name_lookup_opts(apr_int32_t *opts) which will set a variable to be OR-ed with any other appropriate apr_sockaddr_info_get() flags to achieve the proper behavior. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Releasing 2.0.41
While I appreciate the desire to not hold up releases, sometimes just saying we aim for a release at the end of the week or so on, with the RM having the final say, gives people who are lazy by nature (guess who I mean) a nudge to get off their behinds and do something (build/test/fix etc etc). I'm +1 for Sander being RM and +1 for him rolling when he sees fit, just giving another viewpoint :) david At 03:58 PM 9/6/2002, [EMAIL PROTECTED] wrote: On Fri, 6 Sep 2002, Dale Ghent wrote: On Fri, 6 Sep 2002, Greg Stein wrote: | You can always do a 2.0.42 next week if you'd like. argh, we have to remember... Apache 2.0 is GA, not beta! No, it is not. Apache 2.0.40 is GA. Apache 2.0 is a nonentity. 2.0.41 will start out as alpha, then be moved to beta, and finally to GA when and if we believe it is GA quality. Do NOT believe that just because 2.0.40 was GA, 2.0.41 will be too. We specifically said that wasn't true for 2.0. Exactly. The only reason folks may be puzzled by this change is that .40, .39 and .36 flew out the door in pretty much one pass. That's simply because the security bugs they addressed outweighed any comparison. If .41 is worse than .40 (or .36 for that matter) it shouldn't leave beta for GA. Bugs new to .40/.41 get fixed, then .42 will be released (alpha, then beta) and if it's *finally* better than .36 or .40 we can release it GA quality, with the seal of quality We consider Apache 2.0.x to be the best version of Apache available Thanks for reminding us of this, Ryan. Sander, care to tag today even, before the tree is shaken again ;-? Bill
Re: IPv6 capability and name lookup cost
+1 for this and apache wide config flag. david (this discussion assumes Apache has IPv6 capability) There are some situations during normal web server operation where resolver calls are made to find addresses associated with names and we have no clue whether or not the name has an IPv6 address associated with it. Forward proxy is a good example of this. apr_sockaddr_info_get() will return all addresses associated with the name, and some existing resolvers first do IPv4 name lookup followed by IPv6 name lookup in order to implement this. The lack of overlap results in higher elapsed time; the inability to bundle the queries in a single flow results in higher kernel/library CPU. A resolver cache can help with this. In most cases, there is no IPv6 address. In some cases where there is an IPv6 address, using the IPv4 address would be sufficient. A useful performance improvement can be achieved by allowing the administrator to select the following algorithm: lookup IPv4 if at least one IPv4 address was found, we're done lookup IPv6 The benefit is clear. The drawback is that if IPv4 addresses were found but those addresses are not usable (e.g., IPv4 addresses disabled on that machine but admin didn't remove from DNS), we wouldn't then be able to try the IPv6 addresses (without much more work). (But the admin chose the behavior so what do I care :) ) The bulk of the implementation would be in APR (new flag to apr_sockaddr_info_get()), but Apache would have a configuration mechanism to allow the administrator to turn on the flag. Up for discussion would be if there is an Apache-wide preference or whether different components/modules (core, mod_proxy_foo, etc.) should have separate knobs. Personally I'd prefer an Apache-wide preference which would be respected by core and by any modules distributed by us. Any 3rd-party modules could/should respect the configuration too. Comments? (If APR has no IPv6 capability, the new processing flag would be ignored since we're only going to do the IPv4 lookup anyway.) -- Jeff Trawick
Re: [VOTE] Location of aaa rewrite
[X] Check in aaa rewrite to 2.0. [ ] Check in aaa rewrite to 2.1. Why are we suddenly having so many damned votes...
Re: 2.0.40 -- again
The workaround that I put in yesterday will suffice for most installations, but we'll need to revert to the previous poll code in order to have a GA-ready server once again. Then remind me again why we're having a .40 release? If the only crietria is that it's been a while since the last one we shouldn't bother. Users won't follow blindly and we shouldn't release just for the sake of it. If the poll code will be fixed within a week why not wait for that to be done and then test that as the mainstay of a .40 release? That seems to make sense. david
Re: 2.0.40 -- again
Ugh, hate replying to my own emails, but hey sometimes you have to :( OK, so a couple of people have replied off list that it's due to a security exploit. If that's the case then why haven't we done a .40 release before now? Either it's a security problem that warrants a release or it isn't. Which one do we think it is? If it warrants a release then we need to get one done ASAP. If that involves going back to a known poll implementation in APR then so be it, but please let's actually decide what we're trying to achieve here folks and have a go at achieving it. david The workaround that I put in yesterday will suffice for most installations, but we'll need to revert to the previous poll code in order to have a GA-ready server once again. Then remind me again why we're having a .40 release? If the only crietria is that it's been a while since the last one we shouldn't bother. Users won't follow blindly and we shouldn't release just for the sake of it. If the poll code will be fixed within a week why not wait for that to be done and then test that as the mainstay of a .40 release? That seems to make sense. david
Re: HEAD is borked
David Shane Holden wrote: I've noticed this aswell. I have Apache running on a machine using an internal IP and if I connect to it with another machine using an internal IP it sits there for exactly 5 minutes before sending back the respone. But if someone connects with a real IP from the Internet everything works fine. I've tested this on both Win2k and Linux. we belive we have found the problem in the mean time you can use the tag IANH_PRETAG1_2040 as it appears not to have the problem Who's we? Oh, was this more IRC related conversations? david
Re: cvs commit: httpd-2.0/server/mpm/beos beos.c
Well, it didn't, but then we have an extra item on the pollset on top of the num_listening_sockets so that's probably why. david From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Modified:server/mpm/beos beos.c Log: Adjust the sizes of the pollsets we create/use so that we work again. With the poll change we seem to have improved performance. :) This change scares me a bit. The code is supposed to take care of adding the 1 for you. Ryan
Re: PROPOSAL: Release 1.3.25
What about fixing build issues? ab is currently broken on non writev and non ssl platforms (though I have Dirk's patch applied and it correct the issue) and I have one other small patch I'd like to finish and then apply to allow a build for beos to complete... I'll hopefully get the patch done today and send it. I'm +1 on a 1.3.25 though david - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 09, 2002 10:27 PM Subject: PROPOSAL: Release 1.3.25 Now that N+I is winding down, I have some time available. I'd like to propose that we TR 1.3.25 like May 16 or so. I volunteer to be RM. Unless I hear comments against, I'll update STATUS with the schedule and we'll get this ball rolling. Also, I'm also recommending that we officially note the 1.3 tree as in maint.mode only... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Fixing NO_WRIVEV
Will do in a while :)
david
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 02, 2002 11:36 AM
Subject: Fixing NO_WRIVEV
David,
Could you (or someone else) who is on a legitimate platform which does
not support writev() check if this is functional ?
Note that I also found I had to make the #ifdef/#if defined()s to make
things comply across the board.
I've tried both with and without SSL and with/without WRITEV on bsd and
solaris - but obviously 'faking' the four permutations.
Cheers,
Dw
Index: ab.c
===
RCS file: /home/cvs/apache-1.3/src/support/ab.c,v
retrieving revision 1.63
diff -c -3 -r1.63 ab.c
*** ab.c 1 May 2002 17:02:20 - 1.63
--- ab.c 2 May 2002 10:33:09 -
***
*** 114,120
* configure --your-other-options
*/
-
#define VERSION 1.3d
/*
*/
--- 114,119
***
*** 161,167
#endif /* NO_APACHE_INCLUDES */
#ifdef USE_SSL
! #if ((!(RSAREF)) (!(SYSSSL)))
/* Libraries on most systems.. */
#include openssl/rsa.h
#include openssl/crypto.h
--- 160,166
#endif /* NO_APACHE_INCLUDES */
#ifdef USE_SSL
! #if ((!defined(RSAREF)) (!defined(SYSSSL)))
/* Libraries on most systems.. */
#include openssl/rsa.h
#include openssl/crypto.h
***
*** 312,319
#endif
static void close_connection(struct connection * c);
! #if NO_WRITEV || USE_SSL
! static void s_write(struct connection * c, char *buff, int len);
#endif
/* - */
--- 311,318
#endif
static void close_connection(struct connection * c);
! #if (defined(NO_WRITEV) || defined(USE_SSL))
! static int s_write(struct connection * c, char *buff, int len);
#endif
/* - */
***
*** 343,354
/* XXX this sucks - SSL mode and writev() do not mix
* another artificial difference.
*/
! #if !NO_WRITEV !USE_SSL
struct iovec out[2];
! int outcnt = 1, snd = 0;
#endif
gettimeofday(c-connect, 0);
! #if !NO_WRITEV !USE_SSL
out[0].iov_base = request;
out[0].iov_len = reqlen;
--- 342,354
/* XXX this sucks - SSL mode and writev() do not mix
* another artificial difference.
*/
! #if ((!(defined(NO_WRITEV))) (!(defined(USE_SSL
struct iovec out[2];
! int outcnt = 1;
#endif
+ int snd = 0;
gettimeofday(c-connect, 0);
! #if ((!(defined(NO_WRITEV))) (!(defined(USE_SSL
out[0].iov_base = request;
out[0].iov_len = reqlen;
***
*** 387,400
/* Do actual data writing */
! #if NO_WRITEV || USE_SSL
! static void s_write(struct connection * c, char *buff, int len)
{
do {
int n;
! #if USE_SSL
if (ssl) {
! n = SSL_write(c-ssl, buff, len);
if (n 0) {
int e = SSL_get_error(c-ssl, n);
/* propably wrong !!! */
--- 388,402
/* Do actual data writing */
! #if ((defined(NO_WRITEV)) || (defined(USE_SSL)))
! static int s_write(struct connection * c, char *buff, int len)
{
+ int left = len;
do {
int n;
! #ifdef USE_SSL
if (ssl) {
! n = SSL_write(c-ssl, buff, left);
if (n 0) {
int e = SSL_get_error(c-ssl, n);
/* propably wrong !!! */
***
*** 406,412
}
else
#endif
! n = ab_write(c-fd, buff, len);
if (n 0) {
switch (errno) {
--- 408,414
}
else
#endif
! n = ab_write(c-fd, buff, left);
if (n 0) {
switch (errno) {
***
*** 416,424
/* We've tried to write to a broken pipe. */
epipe++;
close_connection(c);
! return;
default:
! #if USE_SSL
if (ssl) {
fprintf(stderr,Error writing: );
ERR_print_errors_fp(stderr);
--- 418,426
/* We've tried to write to a broken pipe. */
epipe++;
close_connection(c);
! return len - left;
default:
! #ifdef USE_SSL
if (ssl) {
fprintf(stderr,Error writing: );
ERR_print_errors_fp(stderr);
***
*** 430,440
}
else if (n) {
if (verbosity = 3)
! printf( -- write(%x) %d (%d)\n, (unsigned char) buff[0], n, len);
buff += n;
! len -= n;
};
! } while (len 0);
}
#endif
--- 432,444
}
else if (n) {
if (verbosity = 3)
! printf( -- write(%x) %d (%d)\n, (unsigned char) buff[0], n, left);
buff += n;
! left -= n;
};
! } while (left 0);
!
! return len-left;
}
#endif
***
*** 879,885
goto _bad;
};
! #if USE_SSL
/*
* move nonblocker - so that measnurement needs to have its OWN
* state engine OR cannot be compared to http.
--- 883,889
goto _bad;
Re: Can AB be compared ?
FWIW, is you don't have writev and are not using ssl, ab in the 1.3 tree is broken and won't even compile at present :( We really should fix it - but maybe the person who broke it could do that as I'm sure they know what they were intending with the changes. david - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 4:05 PM Subject: Can AB be compared ? Just to have some fun - Below is the result of running a build of AB against the same apache 1.3.0 (stock) It is a simple loop - checkout against a tag; cd apache-1.3/src cp Configuration.tmp Configuration ./Configure make cd support make) and then run 20 times ./ab -c 30 -n 1 and take the last 25 runs. By the way - not a -single- tag failed to build on FreeBSD 5-Current and not a single tag needed a differnet config ! A record hard to beat by commercial software ! For each is displayed to total avaerage time/connection; the 98% confidence interval (all in mSec) and the averegate for that version of AB. Note that typically (with eceptiosn early on) each version of AB produces run within the confidence interval - and that successive versions their confidence intertvals do generally not overlap (except early in the development) in the more recent series. So though this shows that comparing versions of AB from different versions is generally waranted (same mean, same SD) - for recent versions of 1.3 - and that comparisions between version no's is not a good idea. BUT at the same time - that has not always been the case - and that is is kind of a miracle (or a tribute to release management/fact that AB hardly ever changed) that comparison is possible. Also if you include 1.3c and 1.3a then you can conclude that these ranges match - thus from these measurements you would conclude that the code did not change substantially (it may of course do for keep alive or something). Dw. Tag checout #define in ab mean/SD aver CI Tag:APACHE_1_3_24 AB: 1.3d66 +-3 66.5 +-3 Tag:APACHE_1_3_23 AB: 1.3d67 +-3 Tag:APACHE_1_3_22 AB: 1.3d67 +-3 Tag:APACHE_1_3_21 AB: 1.3d65 +-3 Tag:APACHE_1_3_20 AB: 1.3c63 +-2 61.8 +-2 Tag:APACHE_1_3_19 AB: 1.3c60 +-2 Tag:APACHE_1_3_18 AB: 1.3c61 +-2 Tag:APACHE_1_3_17 AB: 1.3c61 +-2 Tag:APACHE_1_3_16 AB: 1.3c63 +-2 Tag:APACHE_1_3_15 AB: 1.3c62 +-2 Tag:APACHE_1_3_14 AB: 1.3c63 +-2 Tag:APACHE_1_3_13 AB: 1.3c62 +-2 Tag:APACHE_1_3_12 AB: 1.3c62 +-2 Tag:APACHE_1_3_11 AB: 1.3c60 +-2 Tag:APACHE_1_3_10 AB: 1.3c63 +-2 Tag:APACHE_1_3_9AB: 1.3a60 +-1 60.4 +-1 Tag:APACHE_1_3_8AB: 1.3a61 +-1 Tag:APACHE_1_3_7AB: 1.3a61 +-1 Tag:APACHE_1_3_6AB: 1.3 64 +-2 65.2 +-2 Tag:APACHE_1_3_5AB: 1.3 66 +-3 Tag:APACHE_1_3_4AB: 1.2 61 +-3 62.9 +-3 Tag:APACHE_1_3_3AB: 1.2 61 +-4 Tag:APACHE_1_3_2AB: 1.2 64 +-3 Tag:APACHE_1_3_1AB: 1.1 60 +-9 65.8 +-10 Tag:APACHE_1_3_0AB: 1.1 67 +-6 Tag:APACHE_1_3b7AB: 1.1 64 +-9 Tag:APACHE_1_3b6AB: 1.1 79 +-8 Dw -- Dirk-Willem van Gulik
Re: Final bump and roll of 2.0.36
Ben? Is Ben in the house? david On Wed, May 01, 2002 at 11:40:13PM +0200, Sander Striker wrote: Tarballs are available at: httpd.apache.org/dev/dist/ +1 for beta. Passes httpd-test except for OpenSSL tests which seem to be confused by recent changes in OpenSSL in the Email oid to now be emailAddress. Current OpenSSL snapshots have in crypto/objects/objects.txt: pkcs9 1 : : emailAddress OpenSSL 0.9.6b has in crypto/objects/objects.txt: pkcs9 1 : Email : emailAddress I'll assume that this is why none of the client cert tests are working. *sigh* This doesn't look like anything we can do, but I'm not 100% sure. -- justin
Re: Bumping tags
It looks like you picked up practically all the changes. Why not just retag 2.0.37? I'm +1 for this... You mean, tag HEAD as 2.0.37? I didn't want to do that since there were changes I didn't want in there. Practically all the changes is just about right ;) Well then why are the patches in the tree??? I'm not sure I like the idea of tagging and then tagging just some files. Seems like if we haven't got a stable HEAD we shouldn't be tagging. We got into this whole business of tagging often as a way of avoiding having this sort of thing. Ifw e tagged and it wasn't stable, who cares. Just retag when it is and move on... This seems to be a growing trend and one I think we should stop. david
Re: Atomics in general
I'm more in favour of diabled by default and a switch to enable. If 2.0.36 does look good then binaries will be required (given we have binaries for .35) and I'd rather we avoided too many issues. 2.0.37 won't be far away and maybe we'll have fixed it by then. david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, April 26, 2002 4:10 PM Subject: Re: Atomics in general Jim Jagielski [EMAIL PROTECTED] writes: Maybe we should have atomics disabled by default, at least right now... with the build problems on some Linuxes and the Solaris compatibility stuff, it's been snagging us. I don't want it to delay 2.0.36 if possible. I could go for that or for a --disable-atomic switch which could be used to alleviate any problems if they happen. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c
I think maybe we should move ab out of the tree in this case... david Having it separated out like you have just changed it to is going to cause lots of problems for us maintaining it. While your As to wether this is realistic: From apache-1.3/src/support/ab.c: #define VERSION 1.3d which has been there for some XXX years and allowed us to compare ab results across version releases of apache reliably. I agree that with 2.0 the problem is worse - as we also need to version in APR - and for this reason it may be that we either need to move ab out of the 2.0 tree and into its own space OR also print out the version of APR and the version of Apache it sits in: Version: ab/1.4a Distribution: apache/2.0.35 Apr: apr/2.0.27bis or something along those lines. In general we have a larger can of worms - apache now crucially depends on APR without all that much decoupling - so apache's version number either implies an APR number or the latter needs to be visible. The same fun implies to the tags applied in the tree. Dw
Re: Libtool detection/setting
Thanks. Still unsure about why we have the double detection though... surely using the settings from APR is more correct? david David Reid [EMAIL PROTECTED] writes: Is there any reason why we have the LIBTOOL value hard coded into httpd? I ask as on beos using Jeff's libtool replacement we don't ever need to create a libtool file in the apr directory, so when we try to build using that path it fails. Shouldn't we be using the value that APR has detected and set? Greg and I fixed a problem recently where my libtool didn't put some files in the right place. When I get a chance I'll make sure my latest code is at http://www.apache.org/~trawick and I'll let you know. (I don't know if we're talking about the same issue, but my latest code seems to work with fairly current Apache+APR.) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Libtool detection/setting
Is there any reason why we have the LIBTOOL value hard coded into httpd? I ask as on beos using Jeff's libtool replacement we don't ever need to create a libtool file in the apr directory, so when we try to build using that path it fails. Shouldn't we be using the value that APR has detected and set? david
Fw: [BEOS} Apache 2.0.32 CGI problem
This from a binary of apache 2.0.32 I made and a couple of folks have now reported a problem. This is the best report... - Original Message - From: Nate LaCourse [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 20, 2002 10:37 PM Subject: Re: Quick question about building Apache 2.0.32 There's a problem with one of my CGI scripts. It was there in 2.0.32-beta too. If I access this CGI from the server machine, it's weird. From any other machine, it's fine. Take a look: This is the CGI (it'll take a while to load): http://cibo.dhs.org/cgi-bin/sysinfo.cgi This is a screenshot of me accessing the CGI from the server machine: http://cibo.dhs.org/hold/images/sshot/sundry_bugs/crazy_cgi.jpg Weird, huh? It happens using Opera and BeZilla too. This problem wasn't present in 2.0.28-beta. Anyone any ideas before I blow a while looking for the cause? Looks like the content type isn't getting set?
Re: mod_include???
Following Will's advise to do a make clean;make failed to correct the problem. Here is what i did... cvs update -dP ./buildconf ./configure ... make clean;make rm -rf /usr/local/apache2/* make install cd /usr/local/apache2/bin ./apachectl start And the result? httpd: module mod_include.c is not compatible with this version of Apache. Please contact the vendor for the correct version. This has only been happenning since I last updated (3 days ago). david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 9:27 AM Subject: mod_include??? Just done a cvs update/buildconf/make/make install and I'm seeing an error message that mod_include.c is not compatible with this version of apache! Anyone any ideas? david
Re: mod_include???
FWIW, I've just done an update and build on beos and have the same problem, this time with mod_access. Either I've got something screwy in my build tree's or Houston, we have a problem. david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 10:53 AM Subject: Re: mod_include??? Following Will's advise to do a make clean;make failed to correct the problem. Here is what i did... cvs update -dP ./buildconf ./configure ... make clean;make rm -rf /usr/local/apache2/* make install cd /usr/local/apache2/bin ./apachectl start And the result? httpd: module mod_include.c is not compatible with this version of Apache. Please contact the vendor for the correct version. This has only been happenning since I last updated (3 days ago). david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 9:27 AM Subject: mod_include??? Just done a cvs update/buildconf/make/make install and I'm seeing an error message that mod_include.c is not compatible with this version of apache! Anyone any ideas? david
Re: mod_include???
OK, all seems to have returned to normality, though I have absolutely no idea how/why... david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 12:40 PM Subject: Re: mod_include??? FWIW, I've just done an update and build on beos and have the same problem, this time with mod_access. Either I've got something screwy in my build tree's or Houston, we have a problem. david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 10:53 AM Subject: Re: mod_include??? Following Will's advise to do a make clean;make failed to correct the problem. Here is what i did... cvs update -dP ./buildconf ./configure ... make clean;make rm -rf /usr/local/apache2/* make install cd /usr/local/apache2/bin ./apachectl start And the result? httpd: module mod_include.c is not compatible with this version of Apache. Please contact the vendor for the correct version. This has only been happenning since I last updated (3 days ago). david - Original Message - From: David Reid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 9:27 AM Subject: mod_include??? Just done a cvs update/buildconf/make/make install and I'm seeing an error message that mod_include.c is not compatible with this version of apache! Anyone any ideas? david
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
This also fixes the shutdown issue with worker MPM on FreeBSD which is good :) david brianp 02/01/11 00:01:11 Modified:.CHANGES server/mpm/worker worker.c Log: Fix for a segfault in the worker MPM during graceful shutdown: The per-transaction pools in the worker MPM can't be children of the listener thread's pool, because that pool may go out of scope while some workers are still procesing requests using the transaction pools.
Re: [HEAD] --with-mpm=worker under FreeBSD 4.5 does nothing?
Justin, On FreeBSD 4.5 worker is now reasonably usable (albeit in short bursts I will grant), at least it was for me earlier today. We'll have to play with it and see what's going on on other systems and under load though. david - Original Message - From: Justin Erenkrantz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 4:08 PM Subject: Re: [HEAD] --with-mpm=worker under FreeBSD 4.5 does nothing? On Fri, Jan 11, 2002 at 10:27:18AM -0400, Marc G. Fournier wrote: Morning all ... Just built a 'jail' environment under a 4.5 system so that I can putz around with Apache2-HEAD, where I could reformat at will to clean up any cruft ... build went great, using: #!/bin/sh ./configure \ --prefix=/usr/local/apache \ --with-perl=/usr/bin/perl \ --enable-so \ --with-suexec-caller=nobody \ --with-mpm=worker \ --enable-threads \ --with-port=80 \ --enable-mods-shared='all cgid ssl proxy proxy-connect proxy-ftp proxy-http cache mem-cache file-cache' Install went as smooth ... but I can't connect ... logs/error_log shows: [Fri Jan 11 14:20:17 2002] [info] mod_unique_id: using ip addr 131.162.139.86 [Fri Jan 11 14:20:18 2002] [info] mod_unique_id: using ip addr 131.162.139.86 [Fri Jan 11 14:20:19 2002] [notice] Digest: generating secret for digest authentication ... [Fri Jan 11 14:20:19 2002] [notice] Digest: done [Fri Jan 11 14:20:19 2002] [warn] pid file /usr/local/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [Fri Jan 11 14:20:19 2002] [crit] (78)Function not implemented: Fatal error: could not open(create) scoreboard And a ps listing shows no root process, only the one nobody process: jail# ps aux | grep http nobody 83618 0.0 1.1 4224 2924 ?? IJ2:20PM 0:00.00 bin/httpd Even if I comment out the 'ScoreBoard' line in httpd.conf, it gives the 'Function not implemented' error ... I'm not familiar enough with the jail, but it sounds like anonymous mmap may not be supported in this environment. Can you grep for APR_USE_SHMEM in srclib/apr/include/apr.h and send that? I'll bet mmap is returning that error. Known problem? If not, suggestions on how to debug and provide something just a wee bit more useful? I'm not finding any core files laying about, so nothing I can gdb ... You can do a break in apr_shm_create() and watch the return value from mmap. I bet it'll be an error condition. Please understand that threads aren't working on FreeBSD. It's why you had to manually enable them. =) At the very least, something looks busted with their pthread_cond_* implementation (or our usage of it) that blows up our worker scheme. If you want to help out with the development of worker and threads on FreeBSD, you are more than welcome to assist. I would recommend reading through the various STATUS files for FreeBSD notes. We have tidbits all over the place. However, worker MPM on FreeBSD isn't usable by anyone at this point other than as a conversation piece. -- justin
plog for log files?
Having spent a long time looking at the FreeBSD problem, it finally came
down to stderr being closed and the fd number being resused and causing the
kernel to loop.
It looks like the problem was that we close the sockets when we clean up the
pconf pool, which is bad. Using the plog pool doesn't result in the same
problem as we open the log files just after the pool clear, thus keeping
stderr pointing at something.
Is there any reason why we can't use plog in core.c, as in this patch?
david
Index: core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.126
diff -u -r1.126 core.c
--- core.c 2 Jan 2002 07:56:25 - 1.126
+++ core.c 8 Jan 2002 10:21:48 -
@@ -3361,7 +3361,7 @@
static int core_open_logs(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t
*ptemp, server_rec *s)
{
-ap_open_logs(s, pconf);
+ap_open_logs(s, plog);
return OK;
}
Re: plog for log files?
Huh, we just move the pool for logfiles... Not sure if that qualifies as a workaround. Commit on the way. david - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 08, 2002 3:57 PM Subject: Re: plog for log files? David Reid [EMAIL PROTECTED] writes: Jeff, I think the problem lies in the way that we deal with stderr. basically with threaded freeBSD we have the kernel signal pipe looking at stderr and thus always returning 1, even though there is no signal there to process (this has been checked by both justie and myself). FreeBSD bug... Anyway, if this won't hurt anything then is there any objection to doing it? If there isn't, and given it will cure one bug, I'll commit. I don't want to see us putting in a lot of work-arounds for FreeBSD snafus. If as far as we know just about everything else in threaded Apache works fine on FreeBSD with this patch, then go for it. If this is just one of various outstanding issues, adding the work-around to CVS removes a testcase for anybody wanting to get FreeBSD threading up-to-snuff and it doesn't make Apache work reliably anyway. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server main.c core.c
On Tue, Jan 08, 2002 at 04:30:16PM -, [EMAIL PROTECTED] wrote: dreid 02/01/08 08:30:16 Modified:server main.c core.c Log: This small patch modifies the log's to use plog instead of pconf. Basically pconf is cleared at different times from plog, and this has the effect of leaving stderr closed when going into the next stage of the config. This also had the effect of allowing FreeBSD with threads to create a pipe with stderr's fd at one end, and this resulted in problems with the signal polling and high cpu usage. In addition, move the clearing of plog from main.c to core.c where it seems more appropriate. I don't think that moving the clear call is appropriate. Consider that ap_run_open_logs is a hook. I bet certain third-parties (*ahem* Covalent *ahem*) have their own hook into this function to override the logs. So, core_open_logs isn't guaranteed to be the only caller. I would suggest reverting this section. As long as the pool is cleared *right* before the hook is called, we should be okay. Ah, good point. Shame, it seemed like a neater way of doing it :( david
Re: cvs commit: httpd-2.0/server main.c core.c
So, why were we using pconf??? :) Seems like we've fixed a bug anyways. david On Tuesday 08 January 2002 08:49 am, Justin Erenkrantz wrote: On Tue, Jan 08, 2002 at 04:30:16PM -, [EMAIL PROTECTED] wrote: dreid 02/01/08 08:30:16 Modified:server main.c core.c Log: This small patch modifies the log's to use plog instead of pconf. Basically pconf is cleared at different times from plog, and this has the effect of leaving stderr closed when going into the next stage of the config. This also had the effect of allowing FreeBSD with threads to create a pipe with stderr's fd at one end, and this resulted in problems with the signal polling and high cpu usage. In addition, move the clearing of plog from main.c to core.c where it seems more appropriate. I don't think that moving the clear call is appropriate. Consider that ap_run_open_logs is a hook. I bet certain third-parties (*ahem* Covalent *ahem*) have their own hook into this function to override the logs. So, core_open_logs isn't guaranteed to be the only caller. I would suggest reverting this section. As long as the pool is cleared *right* before the hook is called, we should be okay. As for changing core_open_logs to use plog, I think it is the correct change though upon further review. In fact, if we aren't using plog, I think that is a bug. =) (Because then, it isn't the pool where the logs are from!) -- justin See: http://www.apachelabs.org/apache-mbox/200010.mbox/Pine.LNX.4.21.00101405484 [EMAIL PROTECTED] Just change the ap_run_open_logs call to use plog instead of pconf, and that should solve this problem. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
ap_get_local_host
Is there a reason this isn't using apr functions? david
Re: cvs commit: httpd-2.0 STATUS
On Wed, Jan 02, 2002 at 08:13:33AM -, [EMAIL PROTECTED] wrote: ... lost. This might be an APR issue with how it deals with the child_init hook (i.e. the fcntl lock needs to be resynced). More examination and analysis is required. + + Status: This has also been reported on Cygwin. + + Message-ID: [EMAIL PROTECTED] (cygnus) + + Justin says: So, FreeBSD-CURRENT and Cywin have the same + problem. Yum. If another platform has this + with worker, this becomes a showstopper. Do either platforms pass the tests in APR (testthread, etc)? Can we try and specify EXACTLY what the problem is? We probably need to try and write some tests that expose it so we can debug further. Given how many people will want to use FreeBSD we should probably try hard to find/fix this! I can't seem to get my [recently updated 5.0-CURRENT] FreeBSD box to compile anything except the prefork MPM, no matter what I do, but I must be doing something wrong. Am I the only one with this weird problem? I think Justin was right about using --enable-threads david
Re: Time for and Apache 2.0 Tag and Roll?
I say commit and we'll review. I've also got a patch that I'll try to get to the list tomorrow once I have time to tidy it up a little. david - Original Message - From: Aaron Bannert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 27, 2001 4:31 PM Subject: Re: Time for and Apache 2.0 Tag and Roll? On Thu, Dec 27, 2001 at 11:24:33AM -0500, Jeff Trawick wrote: Bill Stoddard [EMAIL PROTECTED] writes: I'll tag in a few days if I don't hear any dissent. Hopefully Aaron can get his thread-exit fixes in soon? I can commit them right now if we would prefer C-T-R. -aaron
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Brian, Can you check and remove the showstopper if it solves the problem? david aaron 01/12/27 09:06:40 Modified:server/mpm/worker worker.c Log: Take advantage of the new usable apr_thread_exit().
Re: Tagging 2.0.30 in a couple of hours
OK, patch is in and it works a treat. Roll/tag/have fun! david - Original Message - From: Justin Erenkrantz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 28, 2001 7:11 PM Subject: Re: Tagging 2.0.30 in a couple of hours On Fri, Dec 28, 2001 at 01:51:13PM -0500, Bill Stoddard wrote: If my network connection cooperates. I'd like to get feedback from David if my posted apu-conf.m4 patch fixes his configure problem (I bet it will, but I want to be sure). Since I think you'll be doing a tag not just a roll, we can apply this after and you can bump the tag on this file. -- justin
Oh dear...
Try starting the server with another server already running on the same ports. It'll die saying no listening ports available, right? That's cool. useful even. What's not is what it says next. [Fri Dec 28 20:39:26 2001] [alert] no listening sockets available, shutting down [Fri Dec 28 20:39:45 2001] [notice] Apache/2.0.30-dev (Unix) configured -- resuming normal operations Maybe we should see if we can stop the last line from being displayed? david
[PATCH] remove platform specifics
The following patch adds a new include, ap_os.h that has defines
for some of the functions that are currently found in the unixd.h
type headers. It moves these to ap_os and tries to provide no-op
functions for them as appropriate.
This patch enables the worker mpm to build on beos and should
lead to having a single MPM that can at least be built and run
on all platforms.
Tested OK on FreeBSD, Solaris (Aaron) and BeOS.
Aaron gives it +1
Thougts?
david
Index: server/listen.c
===
RCS file: /home/cvs/httpd-2.0/server/listen.c,v
retrieving revision 1.66
diff -u -r1.66 listen.c
--- server/listen.c 8 Dec 2001 01:38:05 - 1.66
+++ server/listen.c 29 Dec 2001 00:23:25 -
@@ -71,6 +71,7 @@
#include http_log.h
#include mpm.h
#include mpm_common.h
+#include ap_os.h
ap_listen_rec *ap_listeners;
#if APR_HAVE_IPV6
Index: server/mpm_common.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm_common.c,v
retrieving revision 1.76
diff -u -r1.76 mpm_common.c
--- server/mpm_common.c 18 Dec 2001 13:48:52 - 1.76
+++ server/mpm_common.c 29 Dec 2001 00:23:27 -
@@ -84,6 +84,7 @@
#include ap_mpm.h
#include ap_listen.h
#include mpm_default.h
+#include ap_os.h
#ifdef AP_MPM_WANT_SET_SCOREBOARD
#include scoreboard.h
@@ -94,6 +95,27 @@
#endif
#ifdef HAVE_GRP_H
#include grp.h
+#endif
+
+#ifdef AP_OS_SETUP_CHILD_IS_NOOP
+AP_DECLARE(int) ap_os_setup_child(void)
+{
+return 0;
+}
+#endif
+
+#ifdef AP_OS_USER_GROUP_ARE_NOOP
+AP_DECLARE(const char *) ap_os_set_user (cmd_parms *cmd, void *dummy,
+ const char *arg)
+{
+return NULL;
+}
+
+AP_DECLARE(const char *) ap_os_set_group(cmd_parms *cmd, void *dummy,
+ const char *arg)
+{
+return NULL;
+}
#endif
#ifdef AP_MPM_WANT_RECLAIM_CHILD_PROCESSES
Index: server/mpm/beos/beos.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/beos/beos.c,v
retrieving revision 1.74
diff -u -r1.74 beos.c
--- server/mpm/beos/beos.c 18 Dec 2001 13:48:53 - 1.74
+++ server/mpm/beos/beos.c 29 Dec 2001 00:23:38 -
@@ -75,7 +75,7 @@
#include http_core.h /* for get_remote_host */
#include http_connection.h
#include ap_mpm.h
-#include beosd.h
+#include ap_os.h
#include ap_listen.h
#include scoreboard.h
#include kernel/OS.h
@@ -948,7 +948,7 @@
/* Time to gracefully shut down:
* Kill child processes, tell them to call child_exit, etc...
*/
-if (beosd_killpg(getpgrp(), SIGTERM) 0)
+if (ap_os_killpg(getpgrp(), SIGTERM) 0)
ap_log_error(APLOG_MARK, APLOG_WARNING, errno, ap_server_conf,
killpg SIGTERM);
@@ -1015,7 +1015,7 @@
server_pid = getpid();
}
-beosd_pre_config();
+ap_os_pre_config(ptemp);
ap_listen_pre_config();
ap_threads_to_start = DEFAULT_START_THREADS;
min_spare_threads = DEFAULT_MIN_FREE_THREADS;
@@ -1129,7 +1129,7 @@
}
static const command_rec beos_cmds[] = {
-BEOS_DAEMON_COMMANDS,
+AP_OS_DAEMON_COMMANDS,
LISTEN_COMMANDS,
AP_INIT_TAKE1( StartThreads, set_threads_to_start, NULL, RSRC_CONF,
Number of threads to launch at server startup),
Index: server/mpm/prefork/mpm.h
===
RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/mpm.h,v
retrieving revision 1.17
diff -u -r1.17 mpm.h
--- server/mpm/prefork/mpm.h13 Nov 2001 22:42:38 - 1.17
+++ server/mpm/prefork/mpm.h29 Dec 2001 00:23:38 -
@@ -59,7 +59,7 @@
#include httpd.h
#include mpm_default.h
#include scoreboard.h
-#include unixd.h
+#include ap_os.h
#ifndef APACHE_MPM_PREFORK_H
#define APACHE_MPM_PREFORK_H
@@ -83,7 +83,7 @@
#define MPM_SYNC_CHILD_TABLE() (ap_sync_scoreboard_image())
#define MPM_CHILD_PID(i) (ap_scoreboard_image-parent[i].pid)
#define MPM_NOTE_CHILD_KILLED(i) (MPM_CHILD_PID(i) = 0)
-#define MPM_ACCEPT_FUNC unixd_accept
+#define MPM_ACCEPT_FUNC ap_os_accept
extern int ap_threads_per_child;
extern int ap_max_daemons_limit;
Index: server/mpm/prefork/prefork.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.226
diff -u -r1.226 prefork.c
--- server/mpm/prefork/prefork.c19 Dec 2001 14:49:22 - 1.226
+++ server/mpm/prefork/prefork.c29 Dec 2001 00:23:39 -
@@ -596,7 +596,7 @@
reopen_scoreboard(pchild);
SAFE_ACCEPT(accept_mutex_child_init(pchild));
-if (unixd_setup_child()) {
+if (ap_os_setup_child()) {
clean_child_exit(APEXIT_CHILDFATAL);
}
@@ -1127,7 +1127,7 @@
/* Time to gracefully shut down:
* Kill child processes, tell them to call child_exit, etc...
*/
- if
unixd_accept
This is defined, but how about we rename it to something without the unixd_ portion so that it's simply a more generic os function, something like ap_os_accept? I ask as I added a beosd_accept and that seems a little clumsy as in the worker MPM I have to then add a series of #if's to get the function used, so simply having an ap_os_accept would solve the problem and seems like an easier way to go. This also seems to apply for some other defines and functions. The definition could even be moved to a more central less os specific setting... Thoughts? david
[PATCH] ap_os_killpg
This basically adds a new define, ap_os_killpg that is intended to
eventually replace the unixd/beosd_killpg.
I've included the change for the worker MPM though I'm sure we can find
other places it could be applied to. OS/2, Netware and Windows haven't
been addressed by this patch (as they don't build the worker MPM at
present).
Thoughts?
david
cvs server: Diffing os/unix
Index: os/unix/unixd.h
===
RCS file: /home/cvs/httpd-2.0/os/unix/unixd.h,v
retrieving revision 1.31
diff -u -r1.31 unixd.h
--- os/unix/unixd.h 2001/11/13 22:42:38 1.31
+++ os/unix/unixd.h 2001/12/25 02:43:24
@@ -125,8 +125,10 @@
#ifdef HAVE_KILLPG
#define unixd_killpg(x, y) (killpg ((x), (y)))
+#define ap_os_killpg(x, y) (killpg ((x), (y)))
#else /* HAVE_KILLPG */
#define unixd_killpg(x, y) (kill (-(x), (y)))
+#define ap_os_killpg(x, y) (kill (-(x), (y)))
#endif /* HAVE_KILLPG */
#define UNIX_DAEMON_COMMANDS \
cvs server: Diffing os/beos
Index: os/beos/beosd.h
===
RCS file: /home/cvs/httpd-2.0/os/beos/beosd.h,v
retrieving revision 1.12
diff -u -r1.12 beosd.h
--- os/beos/beosd.h 2001/12/23 14:13:07 1.12
+++ os/beos/beosd.h 2001/12/25 02:43:24
@@ -91,6 +91,7 @@
apr_pool_t *ptrans);
#define beosd_killpg(x, y) (kill (-(x), (y)))
+#define ap_os_killpg(x, y) (kill (-(x), (y)))
#define BEOS_DAEMON_COMMANDS \
AP_INIT_TAKE1(User, beosd_set_user, NULL, RSRC_CONF, \
Index: server/mpm/worker/worker.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v
retrieving revision 1.53
diff -u -r1.53 worker.c
--- server/mpm/worker/worker.c 2001/12/25 02:34:29 1.53
+++ server/mpm/worker/worker.c 2001/12/25 02:43:24
@@ -1466,7 +1470,7 @@
*/
wake_up_and_die();
-if (unixd_killpg(getpgrp(), SIGTERM) 0) {
+if (ap_os_killpg(getpgrp(), SIGTERM) 0) {
ap_log_error(APLOG_MARK, APLOG_WARNING, errno,
ap_server_conf,
killpg SIGTERM);
}
