On Fri, 17 Oct 2003, Roy T. Fielding wrote:
> It sends 302? Don't you mean it does a subrequest? I'd hope so.
> Anyway, +1 to the patch.
I always thought it did a 302 if the errordocument started with http://
(ie, was possibly external), but did a subrequest if it did not start with
http:// .
Has anyone seen this? Having checked everything possible short of
debugging ab itself, I don't have a clue.
$ ./ab http://127.0.0.1:4874/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.1 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
C
On Friday, October 17, 2003, at 12:27 PM, Jeff Trawick wrote:
For "ErrorDocument nnn http://url";, ap_die() will respond with 302
redirect, and r->status will be updated to indicate that. But the
original error could have been one that keeps us from being able to
process subsequent requests on
For "ErrorDocument nnn http://url";, ap_die() will respond with 302 redirect,
and r->status will be updated to indicate that. But the original error could
have been one that keeps us from being able to process subsequent requests on
the connection. Setting r->status to REDIRECT keeps us from d
On Fri, 17 Oct 2003, Ben Laurie wrote:
> > For this one, it looks like we might need a way to keep track at a
> > global scope what hooks there are. Right now, the only list of hooks is
> > static to the file the hooks were declared in (a static struct called
> > _hooks in that file). Or we co
So it would appear that I want to build mod_perl without the
MP_USE_STATIC=1, is that correct?
That's right. I should have noticed that in your bug report. The static
build is not completed yet. I guess we should do more checking.
Meanwhile just remove that MP_USE_STATIC=1, it'll use MP_USE_DS
Joe Orton wrote:
Graceful restarts can be really slow in 2.0 with prefork... the parent
is making a dummy connection on the pod MaxClients times, rather than a
connection for as many children as it has had; is that really necessary?
We've had problems in this area in the past (not necessarily in pr
Cliff Woolley wrote:
> Noel and I had a little discussion just now on IRC about hook ordering and
> the fact that in 2.0 we have made the admin's life a little harder by
> hard-coding the ordering of certain modules (eg mod_dav vs mod_jk2).
>
> Basically the problem is that a completely automatic
Thanks for the feedback... yeah, it certainly didn't
look right, or consistent, and so the patch seemed
to make sense. But I wanted to double/triple check :)
