Rodent of Unusual Size wrote:
Rodent of Unusual Size wrote:
Syntax error on line 302 of ...extra.conf:
Invalid command 'DAVLockDB', perhaps mis-spelled..
BTW, this caused t/TEST to keep trying to start the server
for a minute. Maybe an 'httpd -t' should be done first
and bail immediately on failur
On Tue, Dec 04, 2001 at 10:09:54AM +, Isabella Pighi wrote:
>
> Hi,
> I applied the patch you posted for mandrake 8.0 and a compiled again flood
> specifying random file and certificate directory.
> The program has problems only dealing with https websites.
>
> ~/flood/httpd-test/flood $ ./
Hi all and Hi Bill(Hope you are happy now), I am a new user of ab. I tried out the precompiled version available at http://www.remotecommunications.com/apache/ab/ When i tried running the application using the command C:\>ab -n 100 http://stc-ntsback/login.asp I got the output as: This is
Hi all apache bench users, There is a lot of UNIX based help available on the net. There are Julian's man pages available too..But what about Windows based help ? Can apache bench be used for testing web pages requiring HTTP POST methods to be excecuted..I mean where some user id and password
Stas Bekman wrote:
>
> Rodent of Unusual Size wrote:
>
> > BTW, this caused t/TEST to keep trying to start the server
> > for a minute. Maybe an 'httpd -t' should be done first
> > and bail immediately on failure? It would short-circuit the
> > minute of waiting when we can *tell* it's not goin
Rodent of Unusual Size wrote:
Stas Bekman wrote:
Rodent of Unusual Size wrote:
BTW, this caused t/TEST to keep trying to start the server
for a minute. Maybe an 'httpd -t' should be done first
and bail immediately on failure? It would short-circuit the
minute of waiting when we can *tell* it's n
On Tue, Dec 04, 2001 at 09:11:31AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz01/12/04 01:11:31
>
> Modified:floodCHANGES
> Log:
> Yo, Aaron, didn't you make some changes? What were they? =)
I forgot about the CHANGES file. :) Glad to see we're making some
good progress on t
On Tue, 27 Nov 2001, Gary Benson wrote:
>
> On Tue, 27 Nov 2001, Rodent of Unusual Size wrote:
>
> > Can it be done?
>
> Not without some trickery: loads of the scripts rely on being able to
> write directly to the server root.
we should fix that. the original plan was for this to work:
% t/
one thing we need to "fix" with this new feature is the ability to turn
off this output. for the same reason we have $ENV{APACHE_TEST_NO_COLOR}
to turn off the colors. for when t/TEST output is redirected to a file,
like from a cron job. at the moment t/TEST > test.log outputs a bunch of
"waiti
On Thu, 22 Nov 2001, Stas Bekman wrote:
> I can extend it to engulf the plan() extension that we have added and then
> the only function you will ever call with plan() is skip_unless. I
> think this:
>
> plan ..., skip_unless('cgi', 'lwp');
there's no point in overloading plan anymore then.
On Fri, 23 Nov 2001, Stas Bekman wrote:
> I've figured out that I have to run many times t/TEST -run
> until it successfully pings the server under t/TEST -d, so I want the
> polling functionality for -run too. Since now we have 3 places where the
> polling happens (start/ping/run), this patch:
i
On Thu, 29 Nov 2001, Rodent of Unusual Size wrote:
> modules\\dav
> ssl\\all
modules.dav
ssl.all
should work on both platforms, since '.' will match the / on unix and \ on
win32.
Doug MacEachern wrote:
one thing we need to "fix" with this new feature is the ability to turn
off this output. for the same reason we have $ENV{APACHE_TEST_NO_COLOR}
to turn off the colors. for when t/TEST output is redirected to a file,
like from a cron job. at the moment t/TEST > test.log out
On Tue, 4 Dec 2001, Stas Bekman wrote:
> Actually, we don't have to run -t to test for failure, since the normal
> execution fails as well and for all cases (not only syntax errors). The
> problem is that we run:
>
>system "command &";
we can run "$cmd -t|" before that and check if the ou
Doug MacEachern wrote:
On Thu, 22 Nov 2001, Stas Bekman wrote:
I can extend it to engulf the plan() extension that we have added and then
the only function you will ever call with plan() is skip_unless. I
think this:
plan ..., skip_unless('cgi', 'lwp');
there's no point in overloading plan anym
Doug MacEachern wrote:
On Fri, 23 Nov 2001, Stas Bekman wrote:
I've figured out that I have to run many times t/TEST -run
until it successfully pings the server under t/TEST -d, so I want the
polling functionality for -run too. Since now we have 3 places where the
polling happens (start/ping/run),
Doug MacEachern wrote:
On Tue, 4 Dec 2001, Stas Bekman wrote:
Actually, we don't have to run -t to test for failure, since the normal
execution fails as well and for all cases (not only syntax errors). The
problem is that we run:
system "command &";
we can run "$cmd -t|" before that and che
On Wed, 5 Dec 2001, Stas Bekman wrote:
> I suggest having an APACHE_TEST_CRON_MODE env var which will also
> replace APACHE_TEST_NO_COLOR. Sounds OK?
i'd just rather have a different name. this'll be useful for more than
cron. in fact i'd be happy to stick with APACHE_TEST_NO_COLOR.
On Wed, 5 Dec 2001, Stas Bekman wrote:
> I didn't get you? do you prefer to make this change and disengage skip
> stuff from plan:
>
> skip_unless(...);
> plan tests => $tests;
i'd like it if the current shorthand continues to work:
plan tests => $tests, ['lwp', 'cgi'];
i would not like i
On Wed, 5 Dec 2001, Stas Bekman wrote:
> I didn't suggest to change how the default -run works (see the patch).
but you did ask:
"- any reason for not making -poll turned on by default for -run?"
> I've suggested a new option -poll, which when used will poll the server
> till it starts. since
Doug MacEachern wrote:
On Wed, 5 Dec 2001, Stas Bekman wrote:
I suggest having an APACHE_TEST_CRON_MODE env var which will also
replace APACHE_TEST_NO_COLOR. Sounds OK?
i'd just rather have a different name. this'll be useful for more than
cron. in fact i'd be happy to stick with APACHE_TEST
On Wed, 5 Dec 2001, Stas Bekman wrote:
> ok, but that catches only syntax errors. if we can catch the return
> status from system() we can catch all errors, causing the failure.
that would be great.
Doug MacEachern wrote:
On Wed, 5 Dec 2001, Stas Bekman wrote:
I didn't get you? do you prefer to make this change and disengage skip
stuff from plan:
skip_unless(...);
plan tests => $tests;
i'd like it if the current shorthand continues to work:
plan tests => $tests, ['lwp', 'cgi'];
i would
Doug MacEachern wrote:
On Wed, 5 Dec 2001, Stas Bekman wrote:
I didn't suggest to change how the default -run works (see the patch).
but you did ask:
"- any reason for not making -poll turned on by default for -run?"
sorry, I've missed this one.
I've suggested a new option -poll, which when
On Wed, 5 Dec 2001, Stas Bekman wrote:
> having two places where the test can be told to skip is confusing.
confusing to who? have you forgotten the perl motto?
> So you only want to preserve:
>
>plan tests => $tests, ['lwp', 'cgi'];
and anything else that currently works, like:
plan te
Doug MacEachern wrote:
>
> one thing we need to "fix" with this new feature is the ability to turn
> off this output. for the same reason we have $ENV{APACHE_TEST_NO_COLOR}
> to turn off the colors. for when t/TEST output is redirected to a file,
> like from a cron job. at the moment t/TEST > t
Doug MacEachern wrote:
>
> > Not without some trickery: loads of the scripts rely on being able to
> > write directly to the server root.
>
> we should fix that. the original plan was for this to work:
> % t/TEST -run -port 8080 -servername foo
>
> and have the .t's hit http://foo:8080
Was 'fo
as was mentioned earlier, some test write to the server root, perhaps we could
add a special directive so you could do something like this in your plan line:
plan tests => 5, have_module 'foo' && have_local_server_root
where 'have_local_server_root' could be named whatever we think appropriate a
On Wed, 5 Dec 2001, Stas Bekman wrote:
> with mnemonic: block until ping and then run? the problem is that ping
> is an exit option, will have to change things a bit.
minor change, see recent commit.
> I still like the new -poll option, since in the future we may extend
> other options funct
On Tue, 4 Dec 2001, Rodent of Unusual Size wrote:
> Was 'foo' supposed to be a vhost on the current system, or
> was it supposed to be able to be a remote system? The
> latter is my goal (testing things like DAV on Win32 bites
> the Harry Houdini..).
the latter.
30 matches
Mail list logo
