|
Posted by steve.yost on December 21, 2007, 11:20 pm
Please log in for more thread options
My site has been humming along in blissful ignorance of the latest
Perl happenings for several years, running Perl 5.6.0, Apache 1.3, and
whatever version of mod_perl was current. I use CGI.pm to do request
parsing and response output, because the whole site used to be
<shudder> CGI scripts.
I'm in the process of upgrading to Perl 5.8.8, Apache 2.0, and
ModPerl::Registry, and CGI.pm v3.29.
Right now, all the redirects I do that follow POSTs are broken. They
produce status 200 instead of status 303 that I coded for. Any ideas
why or other advice?
Thanks very much.
Here's a stripped down bit of sample code:
my @headerargs = ('-cookie', $my_cookie) if $my_cookie;
my @redirargs =
('-Status', '303 See Other',
'-Location', $forward_url,
'-URL', $forward_url);
push (@headerargs, @redirargs);
print $cgi->header(@headerargs);
# print some text ...
exit();
-Steve
|
|
Posted by Claudio Calvelli on December 22, 2007, 2:06 am
Please log in for more thread options
> I'm in the process of upgrading to Perl 5.8.8, Apache 2.0, and
> ModPerl::Registry, and CGI.pm v3.29.
> Right now, all the redirects I do that follow POSTs are broken. They
> produce status 200 instead of status 303 that I coded for. Any ideas
> why or other advice?
> Thanks very much.
The CGI.pm documentation suggests to use redirect rather than header
to creating redirections, so something along the lines of:
print $cgi->redirect(-uri=>$otherurl, -status=>303)
should work.
C
--
The address in the "From" header won't work. Email to "usenet" at "intercal" dot
"dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages
to go through the spam filter, and other conditions which I won't disclose.
|
|
Posted by steve.yost on December 22, 2007, 10:47 am
Please log in for more thread options On Dec 22, 2:06 am, Claudio Calvelli
>
> > I'm in the process of upgrading to Perl 5.8.8, Apache 2.0, and
> > ModPerl::Registry, and CGI.pm v3.29.
> > Right now, all the redirects I do that follow POSTs are broken. They
> > produce status 200 instead of status 303 that I coded for. Any ideas
> > why or other advice?
> > Thanks very much.
>
> The CGI.pm documentation suggests to use redirect rather than header
> to creating redirections, so something along the lines of:
>
> print $cgi->redirect(-uri=>$otherurl, -status=>303)
>
> should work.
>
> C
Thanks for the reply, Claudio. That didn't help, but I did find that
the problem was resolved by not printing any text after the header.
Apparently with text printed, CGI.pm reverts that status back to 200,
which seems reasonable. If you're redirecting, you shouldn't need any
text, and if you succesfully produce a web page, it's reasonable that
the status be 200.
So the status was coming through as 200 but there was a location in
the http header, which let to the result being a page that said:
OK
The answer to your request is located here
with *here* being a link to the url I was forwarding to.
The text was legacy support for browsers that might not support
forwarding (my service has been around since 1999!).
Hope all this helps anyone else that runs into this problem.
Steve
|
|
Posted by Claudio Calvelli on December 22, 2007, 4:08 pm
Please log in for more thread options > Thanks for the reply, Claudio. That didn't help, but I did find that
> the problem was resolved by not printing any text after the header.
> Apparently with text printed, CGI.pm reverts that status back to 200,
> which seems reasonable. If you're redirecting, you shouldn't need any
> text, and if you succesfully produce a web page, it's reasonable that
> the status be 200.
It looks like it's mod_perl which does that.
I put the following script both in $DOCUMENTROOT/cgi-bin/test.cgi and
$DOCUMENTROOT/perl/test.cgi:
---- cut here ---- script ----
#!/usr/bin/perl -w
use strict;
use CGI;
my $cgi = new CGI;
my $location = 'http://www.some-otherp-lace.com/';
print $cgi->redirect( -uri => $location, -status => 303);
print "... and if you aren't automatically redirected, see <a
href=\"$location\">here</a>\n";
---- cut here ----
The cgi-bin version works as expected:
----
GET /cgi-bin/test.cgi HTTP/1.0
HTTP/1.1 303 See Other
Date: Sat, 22 Dec 2007 21:02:58 GMT
Server: Apache
Location: http://www.some-otherp-lace.com/
Connection: close
Content-Type: text/plain
... and if you aren't automatically redirected, see <a
href="http://www.some-otherp-lace.com/">here</a>
----
The mod_perl version changes the 303 to 200:
----
GET /perl/test.cgi HTTP/1.0
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2007 21:05:05 GMT
Server: Apache
Location: http://www.some-otherp-lace.com/
Connection: close
Content-Type: text/plain
... and if you aren't automatically redirected, see <a
href="http://www.some-otherp-lace.com/">here</a>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>200 OK</title>
</head><body>
<h1>OK</h1>
<p>The answer to your request is located <a
href="http://www.some-otherp-lace.com/">here</a>.</p>
</body></html>
----
Note how the status becomes 200, and a whole new document with the redirect
is added after the text!
C
--
The address in the "From" header won't work. Email to "usenet" at "intercal" dot
"dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages
to go through the spam filter, and other conditions which I won't disclose.
|
|
Posted by None on December 22, 2007, 5:37 pm
Please log in for more thread options On Dec 22, 4:08 pm, Claudio Calvelli
> It looks like it's mod_perl which does that.
>
Precisely. Nice test!
Thanks,
Steve
|
| Similar Threads | Posted | | CPAN conflict issue - CGI.pm vs ModPerl::Registry | September 25, 2006, 12:42 pm |
| modperl and apache handlers | December 28, 2004, 5:38 am |
| How to use Registry functions | January 30, 2006, 8:47 am |
| perl : Importing registry keys | February 3, 2005, 11:34 am |
| Windows Registry manipulation using Unix | April 29, 2005, 11:46 am |
| Module to use for win32 registry access? | April 4, 2007, 8:32 pm |
|
XML Sitemap