You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2003/10/11 03:49:11 UTC
[apreq-2] redirect on Win32
Hi,
There seems to be a problem with the apreq_redirect_test
on Win32 with apreq-2. First off, env/t/request.t gives
the results in the attached t1.txt, with the error log
being e1.txt. The problem here is that no location is
extracted (in e1.txt, there's debug messages from
mod_apreq_redirect_test.c saying "looking for new location",
but no corresponding "redirecting to / ..." twin. If I
apply the following to env/t/request.t:
==========================================================
Index: t/request.t
===================================================================
RCS file: /home/cvs/httpd-apreq-2/env/t/request.t,v
retrieving revision 1.6
diff -u -r1.6 request.t
--- t/request.t 1 Oct 2003 20:00:36 -0000 1.6
+++ t/request.t 11 Oct 2003 01:26:57 -0000
@@ -19,7 +19,7 @@
ok t_cmp(403, GET_RC("/apreq_access_test"), "access denied");
-my $filler = "0123456789" x 6400; # < 64K
+my $filler = "0123456789"; # < 64K
my $body = POST_BODY("/apreq_access_test?foo=1;",
content => "bar=2&quux=$filler;test=6&more=$filler");
ok t_cmp(<<EOT, $body, "prefetch credentials");
@@ -36,10 +36,10 @@
foreach my $location ('/apreq_request_test', '/apreq_access_test') {
ok t_cmp("ARGS:\n\ttest => redirect\n",
- GET_BODY("/apreq_redirect_test?test=ok&location=$location%3Ftest=redirect"),
+ GET_BODY("/apreq_redirect_test?test=ok&location=$location&test=redirect"),
"redirect GET");
- $body = POST_BODY("/apreq_redirect_test?location=$location%3Ffoo=bar", content =>
+ $body = POST_BODY("/apreq_redirect_test?location=$location&foo=bar", content =>
"quux=$filler;test=redirect+with+prefetch;more=$filler");
ok t_cmp(<<EOT, $body, "redirect with prefetch");
============================================================================
(I changed the size of $filler for ease of debugging), then
the results of env/t/request.t occur in t2.txt, with the
error log being e2.txt. In this case the redirect does
happen, but it's just to, eg, /apreq_access_test, without
the rest of the args needed for the tests.
This is with Apache/2.0.47. Does the above suggest anything
to try? Thanks.
--
best regards,
randy
Re: [apreq-2] redirect on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 11 Oct 2003, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> [...]
>
> > -GET_BODY("/apreq_redirect_test?test=ok&location=$location%3Ftest=redirect"),
> > +GET_BODY("/apreq_redirect_test?test=ok&location=$location&test=redirect"),
> ^
> ^
> %3F is "?", not "&". Try the tests again with the shortened 10-byte
> $filler and "?" instead of "&". Do all 4 redirect tests still fail?
Yes, they fail the same way as with %3F - no redirect at all
is attempted (ie, in mod_apreq_redirect_test.c, loc is
null).
--
best regards,
randy
Re: [apreq-2] redirect on Win32
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> -GET_BODY("/apreq_redirect_test?test=ok&location=$location%3Ftest=redirect"),
> +GET_BODY("/apreq_redirect_test?test=ok&location=$location&test=redirect"),
^
^
%3F is "?", not "&". Try the tests again with the shortened 10-byte
$filler and "?" instead of "&". Do all 4 redirect tests still fail?
--
Joe Schaefer
Re: [apreq-2] redirect on Win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 11 Oct 2003, Joe Schaefer wrote:
>
>
>>I now remember seeing this condition when I first wrote the
>>tests. There was a bug in apreq_parse_query_string() that disallowed
>>"=" signs in parameter values. I bet you're linking against
>>an older, installed version of libapreq instead of one built
>>from current cvs (the fix to apreq_params.c was applied when
>>I added the redirect tests last week).
>
>
> You're right (blush :) Thanks very much - the tests are
> all fine now, with the original env/t/request.t.
Both, mod_perl and libapreq users (and developers) quite often suffer from
this problem. Long ago I have suggested to have some magic number check, which
will verify that .so and .pm that are being loaded are from the same build.
Unfortunately I never had a chance to implement it. If apreq does it first,
I'll sure thing "steal" it for mod_perl ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [apreq-2] redirect on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 11 Oct 2003, Joe Schaefer wrote:
> I now remember seeing this condition when I first wrote the
> tests. There was a bug in apreq_parse_query_string() that disallowed
> "=" signs in parameter values. I bet you're linking against
> an older, installed version of libapreq instead of one built
> from current cvs (the fix to apreq_params.c was applied when
> I added the redirect tests last week).
You're right (blush :) Thanks very much - the tests are
all fine now, with the original env/t/request.t.
--
best regards,
randy
Re: [apreq-2] redirect on Win32
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> Hi,
> There seems to be a problem with the apreq_redirect_test
> on Win32 with apreq-2. First off, env/t/request.t gives
> the results in the attached t1.txt, with the error log
> being e1.txt. The problem here is that no location is
> extracted (in e1.txt, there's debug messages from
> mod_apreq_redirect_test.c saying "looking for new location",
> but no corresponding "redirecting to / ..." twin.
I now remember seeing this condition when I first wrote the
tests. There was a bug in apreq_parse_query_string() that disallowed
"=" signs in parameter values. I bet you're linking against
an older, installed version of libapreq instead of one built
from current cvs (the fix to apreq_params.c was applied when
I added the redirect tests last week).
--
Joe Schaefer