On Oct 26, 2004, at 10:00 AM, Geoffrey Young wrote:
that's not so bad, but it will affect users somewhat - I know that I
have
used it in at least one of my tests...
Bleh. Bad Geoff!
maybe keeping $RedirectOK but moving the perl-framework (and mod_perl)
over
to the new API would be a nice compromi
On Mon, Oct 25, 2004 at 06:47:12PM -0700, David Wheeler wrote:
> No, just hacking. Let's see...oh, I get it. I changed it so that it
> ignored $RedirectOK if LWP was installed.
Thanks David. No comments here on what's right, only what works ;)
> You know, I'm inclined to remove that stupid $RedirectOK global
> variable, because you can't tell whether it was set by the user of
> Apache::TestRequest. This makes it difficult to decide whether or not to
> let LWP handle the call to redirect_ok(). What say you all to my
> changing this to a
On Oct 25, 2004, at 4:33 PM, Geoffrey Young wrote:
let's give david a chance to investigate - either to fix or, if a
quick fix
isn't obvious, revert the behavior.
if david doesn't respond by, say, wednesday, we (you or I) should feel
free
to just revert the change. maybe david is on vacation or
Joe Orton wrote:
> On Sun, Oct 24, 2004 at 11:37:11AM +0100, Joe Orton wrote:
>
>>On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
>>
>>>theory 2004/10/22 15:09:54
>>>
>>> Modified:perl-framework/Apache-Test Changes
>>> perl-framework/Apache-Test/lib/Apa
On Sun, Oct 24, 2004 at 11:37:11AM +0100, Joe Orton wrote:
> On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
> > theory 2004/10/22 15:09:54
> >
> > Modified:perl-framework/Apache-Test Changes
> >perl-framework/Apache-Test/lib/Apache TestRequest.pm
> >
On Fri, Oct 22, 2004 at 10:09:54PM -, [EMAIL PROTECTED] wrote:
> theory 2004/10/22 15:09:54
>
> Modified:perl-framework/Apache-Test Changes
>perl-framework/Apache-Test/lib/Apache TestRequest.pm
> Log:
> Redirect from POST fixes (or prevention, depending on how yo
David Wheeler wrote:
> On Jul 31, 2004, at 5:04 PM, Stas Bekman wrote:
>
>>> I guess losing the skip message by making need_ functions that
>>> replace the existing have_ functions is okay. It's most important
>>> that tests continue to pass...
>>
>>
>> They will.
>
>
> Then I say we go with n
On Jul 31, 2004, at 5:04 PM, Stas Bekman wrote:
I guess losing the skip message by making need_ functions that
replace the existing have_ functions is okay. It's most important
that tests continue to pass...
They will.
Then I say we go with need.
Regards,
David
smime.p7s
Description: S/MIME cry
David Wheeler wrote:
On Jul 31, 2004, at 9:46 AM, Stas Bekman wrote:
to me, got and have are exactly the same thing. How are you going to
remember which one to use when?
Yes, I will. :-)
Authors of the existing tests don't have to change anything, have_foo
will work just the same, but won't add
On Jul 31, 2004, at 9:46 AM, Stas Bekman wrote:
to me, got and have are exactly the same thing. How are you going to
remember which one to use when?
Yes, I will. :-)
Authors of the existing tests don't have to change anything, have_foo
will work just the same, but won't add the skip reason anymor
Stas Bekman wrote:
[...]
But, yes, the transition could be made 100% perfect, by keeping have_ as
it is, and adding a new interface which doesn't add the skip reason. But
we need to find an unambiguous name for it. skip_foo will be good, but
we have a general function have(), which can't be repl
David Wheeler wrote:
On Jul 31, 2004, at 1:14 AM, Stas Bekman wrote:
so, have_foo is intuitive to be used anywhere in the code, and plan
now will look like:
plan tests => 5, need_lwp, need_cgi, need_php;
I like this, but isn't it putting the onus of change on module owners
and introducing the l
On Jul 31, 2004, at 1:14 AM, Stas Bekman wrote:
so, have_foo is intuitive to be used anywhere in the code, and plan
now will look like:
plan tests => 5, need_lwp, need_cgi, need_php;
I like this, but isn't it putting the onus of change on module owners
and introducing the likelihood of unexpecte
Geoffrey Young wrote:
Using have_ macros for non-plan() usage should be avoided, since it
populates the SKIP messages array and if later the test is skipped, for
a different reason it'll misleadingly tell the user that LWP was also a
requirement for that test (which quite possibly could be what we
> Using have_ macros for non-plan() usage should be avoided, since it
> populates the SKIP messages array and if later the test is skipped, for
> a different reason it'll misleadingly tell the user that LWP was also a
> requirement for that test (which quite possibly could be what we want).
>
> We
[EMAIL PROTECTED] wrote:
theory 2004/07/30 19:43:33
+ # Always allow redirection.
+ my $redir = have_lwp ? [qw(GET HEAD POST)] : 1;
+ Apache::TestRequest::user_agent(reset => 1,
+ requests_redirectable => $redir);
Using have_ macros for non-plan() u
David Wheeler wrote:
On Friday, July 11, 2003, at 09:27 AM, Sander Temme wrote:
The above patch doesn't work. But this does:
Ehm... works for me. I think you're working in the mod_perl space and I'm
just concentrating on the Apache core. Maybe there are side effects
that I'm
not seeing?
Yes, th
On Friday, July 11, 2003, at 09:27 AM, Sander Temme wrote:
The above patch doesn't work. But this does:
Ehm... works for me. I think you're working in the mod_perl space and
I'm
just concentrating on the Apache core. Maybe there are side effects
that I'm
not seeing?
Yes, the redirect_ok subrouti
on 7/11/03 9:06, David Wheeler at [EMAIL PROTECTED] wrote:
> The above patch doesn't work. But this does:
Ehm... works for me. I think you're working in the mod_perl space and I'm
just concentrating on the Apache core. Maybe there are side effects that I'm
not seeing?
> --- TestRequest.pm.~1.8
On Friday, July 11, 2003, at 02:22 AM, Stas Bekman wrote:
diff -u -r1.81 TestRequest.pm
--- Apache-Test/lib/Apache/TestRequest.pm 8 Jul 2003 07:56:24
-
1.81
+++ Apache-Test/lib/Apache/TestRequest.pm 11 Jul 2003 04:28:45
-
@@ -88,14 +88,12 @@
$UA = undef;
}
-
Sander Temme wrote:
on 7/10/03 18:00, Stas Bekman at [EMAIL PROTECTED] wrote:
Does this work?
else if ($redir) {
$RedirectOK = $redir;
}
It does. However, isn't this the same condition as in the top if clause?
Wouldn't you want to:
Index: Apache-Test/lib/Apache/TestRequest.pm
==
on 7/10/03 18:00, Stas Bekman at [EMAIL PROTECTED] wrote:
>
> Does this work?
>
> else if ($redir) {
>$RedirectOK = $redir;
> }
It does. However, isn't this the same condition as in the top if clause?
Wouldn't you want to:
Index: Apache-Test/lib/Apache/TestRequest.pm
==
Sander Temme wrote:
on 7/10/03 12:56, Sander Temme at [EMAIL PROTECTED] wrote:
parameter to the request invocations in t/apache/acceptpathinfo.t. Neither
produces any result. Am I looking in the right place?
Breadcrumbing my way through Apache-Test/lib/Apache/TestRequest.pm by
liberally sprinklin
on 7/10/03 12:56, Sander Temme at [EMAIL PROTECTED] wrote:
> parameter to the request invocations in t/apache/acceptpathinfo.t. Neither
> produces any result. Am I looking in the right place?
Breadcrumbing my way through Apache-Test/lib/Apache/TestRequest.pm by
liberally sprinkling print statemen
on 7/8/03 0:28, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
> stas2003/07/08 00:28:28
>
> Modified:perl-framework/Apache-Test/lib/Apache TestRequest.pm
> Log:
> Change the way the redirect_ok parameter works so that it affects only
> _that call_ to the function. Afterward it should
[EMAIL PROTECTED] wrote:
>
> Work correctly when the response is empty, for instance when we
> are pinging the server to see if it has warmed up yet.
Unfortunately, this is misleading -- because you get this
message even if the server doesn't answer at all, not just
if the response-line is in
27 matches
Mail list logo
