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 '^]'.
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
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
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/
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
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
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
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?
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 ]
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
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
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
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
So auth changing folks, what replaces limitexcept? It's not working on
trunk at present as far as I can tell...
david
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
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
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 @@
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
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
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
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
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
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
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
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
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
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
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
-1
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
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
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:
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))
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
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
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
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,
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
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
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
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
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
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
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
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
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
-
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
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
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
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:
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
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
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
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
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.
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
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
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
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
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:
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
+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
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
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
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
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).
+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
[X] Check in aaa rewrite to 2.0.
[ ] Check in aaa rewrite to 2.1.
Why are we suddenly having so many damned votes...
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
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.
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
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
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
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Is there a reason this isn't using apr functions?
david
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:
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
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().
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,
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
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
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
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
1 - 100 of 112 matches
Mail list logo
