On Tue, 23 Apr 2002, Aaron Bannert wrote:
> This patch corrects some problems in the ability of AB to handle
> concurrent processing by:
> - enabling nonblocking connect()s.
> - preventing APR from performing blocking reads, allowing AB to
>multiplex over its own set of descriptors.
> ** If
On Thu, Apr 18, 2002 at 07:33:54AM -0500, William A. Rowe, Jr. wrote:
>...
> If I can get that semantics change done on optional fns/hooks so we can
> avoid all mmn version bumps for optional fn/hooks, I think that would also
> cut down on the bumps for foreign modules. Will look to make some
> p
And copying the ,v files messes with history!
Damn. Will people just never realize this? Go and check out a copy of the
tree by date. Oh! it's fucked. Somebody copied a ,v file.
It isn't all about tags. Use add and rm, with a pointer in the initial
checkin comment to where the file came from (an
On Tue, Apr 23, 2002 at 05:04:10PM -0700, Aaron Bannert wrote:
> This patch corrects some problems in the ability of AB to handle
> concurrent processing by:
Oh, and the reason I posted this instead of just committing was because
AB is a nasty beast and I wanted to make sure I didn't break anythi
This patch corrects some problems in the ability of AB to handle
concurrent processing by:
- enabling nonblocking connect()s.
- preventing APR from performing blocking reads, allowing AB to
multiplex over its own set of descriptors.
Pre-patch: worker MPM with 2 children, 10 threads each: 10
On Tue, 23 Apr 2002, Bill Stoddard wrote:
> We have the exact same issue with mod_cache
> (mod_mem_cache/mod_disk_cache). What do you think about hiding the load
> of the protocol modules behind a config directive?
I don't have a conceptual problem with that, though it would mean
hardcoding the
> On 23 Apr 2002 [EMAIL PROTECTED] wrote:
>
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8407
> > reverse proxy return FORBIDDEN all the time
> >
> > --- Additional Comments From [EMAIL PROTECTED] 2002-04-23 17:25
>---
> > I loaded additionnal mod_proxy modules (mod_proxy_http.s
On Tue, 23 Apr 2002, Greg Ames wrote:
> > Sheesh. Anyone know how to fix that?
>
> you aren't going to like my fixes...
>
> * use static builds for debugging
> * upgrade the OS
I ended up upgrading gdb from 5.0 to 5.1.1 and building it for i686
instead of i386, and between those two changes, it
On 23 Apr 2002 [EMAIL PROTECTED] wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8407
> reverse proxy return FORBIDDEN all the time
>
> --- Additional Comments From [EMAIL PROTECTED] 2002-04-23 17:25
>---
> I loaded additionnal mod_proxy modules (mod_proxy_http.so, mod_proxy_
On Tue, Apr 23, 2002 at 10:53:32AM -0700, Aaron Bannert wrote:
> (We probably don't want to be installing the *.conf.in files too,
> but that's a different problem.)
>
Yes, but still something that would be nice to fix - the .in files
just adds unnecessary confusion IMHO.
vh
Mads Toftum
--
Wit
Cliff Woolley wrote:
> However, I guess I should have kept my eyes open to what gdb was telling
> me:
>
> warning: Unable to find dynamic linker breakpoint function.
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code.
that sounds familiar
> Sh
Justin Erenkrantz wrote:
>
> The reason I suggested a hold to Sander on account of the atomics
> is that we have a bunch of PRs relating to building atomics on
> Solaris that haven't been (yet) resolved.
>
Hold on a tic... I think I see it... On the systems that fail,
I bet they are using GNUas
On Tue, Apr 23, 2002 at 10:35:58AM -0700, Justin Erenkrantz wrote:
> This patch should fix PR 8227.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8227
>
> Is there any reason to use @@ServerRoot@@ (and the reason why
> I'm posting instead of committing right away)? -- justin
I haven't
You know, I don't see this but I wonder if the reason why is because
on those systems where it fails, /usr/ccs/bin isn't in their path...
Justin Erenkrantz wrote:
>
> The reason I suggested a hold to Sander on account of the atomics
> is that we have a bunch of PRs relating to building atomics o
On Tue, Apr 23, 2002 at 02:00:25PM +0200, Sander Striker wrote:
> Hi,
>
> I volunteer to be RM for 2.0.36 (that is, if noone
> has a problem with that ;).
>
> I'm aware of the issues we still have in HEAD, which
> is why we need a tag and run that on daedalus.
>
> However, I'll hold of on the t
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> Sent: 23 April 2002 19:36
> This patch should fix PR 8227.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8227
+1 on the patch. We shouldn't mess with path concatenation
like we are doing currently; it's asking for trouble.
> Is th
This patch should fix PR 8227.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8227
Is there any reason to use @@ServerRoot@@ (and the reason why
I'm posting instead of committing right away)? -- justin
Index: docs/conf/httpd-std.conf.in
==
+1
> Hi,
>
> I volunteer to be RM for 2.0.36 (that is, if noone
> has a problem with that ;).
>
> I'm aware of the issues we still have in HEAD, which
> is why we need a tag and run that on daedalus.
>
> However, I'll hold of on the tag since there are
> probably going to be some file moves in
Hi,
I volunteer to be RM for 2.0.36 (that is, if noone
has a problem with that ;).
I'm aware of the issues we still have in HEAD, which
is why we need a tag and run that on daedalus.
However, I'll hold of on the tag since there are
probably going to be some file moves in the atomics
section. W
> 1. In order to do the setuid, the server would need to be running as
> root during the request processing phase. Any bug in Apache request
> processing would then open an instant root hole.
Yes, that's a major problem.
> 2. If you setuid in such a way that you can get back to the original
20 matches
Mail list logo
