Re: Easy internal redirect question
[EMAIL PROTECTED] wrote:
I've got a bit of a better grasp on the problem nowI think it's an
interaction with POST data...
I have a form in foo.html
form action=/rms/admin method=post
input type=hidden name=task value=process_config
...other form fields...
/form
I submit this form, and in /rms/admin, it gets handled like this
# suck in form values, stick them in objects, blah blah, then get to the
redirect...
$r-internal_redirect('/rms/status?task=display');
and what happens is that /rms/status complains that it doesn't know how to
handle task=process_config. So, somehow the value for 'task' that was
POSTed in the first request from the form gets passed onto the second
request, apparently overriding the
'task' value of 'display' which I am trying to set in the url string I'm
giving to internal_redirect().
you can only read POST data once, so once it's slurped from the main
request it's gone unless you store it someplace. for it to show up in
the internal redirect (outside of your object) you'd have to follow
the example of changing a POST to a GET and stuffing the POST data in
the query string (using something similar to recipe 3.18 and/or the
example in the Guide).
so, it sounds like your object is bleeding data over from the main
request into the redirect.
I don't want any of the POST data to get passed onto that redirect.
it shouldn't be there. try reading from $r-content and $r-args in
the redirect and see what you find.
Any
thoughts? I saw a note in the API docs that $r-args() can be used to set
the query string and that this is useful when redirecting POST requests. I
tried doing a $r-args('task=display') right before the call to
internal_redirect, but no luck.
setting $r-args in the main request won't bleed over either. I went
through the code for ap_internal_redirect yesterday and it definitely
takes the query string from the passed in URI.
HTH
--Geoff
RE: Easy internal redirect question
After further review, the problem was CGI.pm. CGI.pm doesn't appear to get
'reset' on an internal_redirect (I'm not familiar with CGI's support for
mod_perl, so maybe this should have been obvious!) so it was still holding
the old parameter values. A quick install of Apache::Request and a call to
$r-param('task') give much better results. CGI was a remnant from our
pre-mod_perl days and I've been meaning to get rid of it for a while.
Thanks,
Fran
Easy internal redirect question
I call a page, /my/script1?task=foo which does some things and then needs to
redirect to /my/script2?task=bar. However, putting
$r-internal_redirect('/my/script2?task=bar');
doesn't seem to work as script2 is seeing task=foo rather than task=bar.
Looks like the internal_redirect is also passing along the form params to
the second request. How is this avoided? I'm looking through the cookbook
recipe on internal redirects but nothing is jumping out at me at the moment.
Thanks,
Fran
Re: Easy internal redirect question
[EMAIL PROTECTED] wrote:
I call a page, /my/script1?task=foo which does some things and then needs to
redirect to /my/script2?task=bar. However, putting
$r-internal_redirect('/my/script2?task=bar');
doesn't seem to work as script2 is seeing task=foo rather than task=bar.
Looks like the internal_redirect is also passing along the form params to
the second request. How is this avoided? I'm looking through the cookbook
recipe on internal redirects but nothing is jumping out at me at the moment.
that's pretty odd.
given two scripts, one.pl:
shift-internal_redirect('/perl-bin/two.pl?internal=redirect');
return Apache::OK;
and two.pl:
my $r = shift;
$r-send_http_header('text/plain');
print args is , scalar $r-args, \n;
I get the right results:
$ GET localhost/perl-bin/one.pl?main=request
args is internal=redirect
are you returning OK right after your internal redirect? does setting
$r-args() before calling the internal redirect to a third value
change anything?
--Geoff
RE: Easy internal redirect question
I've got a bit of a better grasp on the problem nowI think it's an
interaction with POST data...
I have a form in foo.html
form action=/rms/admin method=post
input type=hidden name=task value=process_config
...other form fields...
/form
I submit this form, and in /rms/admin, it gets handled like this
# suck in form values, stick them in objects, blah blah, then get to the
redirect...
$r-internal_redirect('/rms/status?task=display');
and what happens is that /rms/status complains that it doesn't know how to
handle task=process_config. So, somehow the value for 'task' that was
POSTed in the first request from the form gets passed onto the second
request, apparently overriding the
'task' value of 'display' which I am trying to set in the url string I'm
giving to internal_redirect().
I don't want any of the POST data to get passed onto that redirect. Any
thoughts? I saw a note in the API docs that $r-args() can be used to set
the query string and that this is useful when redirecting POST requests. I
tried doing a $r-args('task=display') right before the call to
internal_redirect, but no luck.
Thanks,
Fran
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 1:06 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Easy internal redirect question
[EMAIL PROTECTED] wrote:
I call a page, /my/script1?task=foo which does some things and then needs
to
redirect to /my/script2?task=bar. However, putting
$r-internal_redirect('/my/script2?task=bar');
doesn't seem to work as script2 is seeing task=foo rather than task=bar.
Looks like the internal_redirect is also passing along the form params to
the second request. How is this avoided? I'm looking through the
cookbook
recipe on internal redirects but nothing is jumping out at me at the
moment.
that's pretty odd.
given two scripts, one.pl:
shift-internal_redirect('/perl-bin/two.pl?internal=redirect');
return Apache::OK;
and two.pl:
my $r = shift;
$r-send_http_header('text/plain');
print args is , scalar $r-args, \n;
I get the right results:
$ GET localhost/perl-bin/one.pl?main=request
args is internal=redirect
are you returning OK right after your internal redirect? does setting
$r-args() before calling the internal redirect to a third value
change anything?
--Geoff
