Help! - Need a CGI redirect which passes a querystring value

[Damon]

Hi all,

I'm not very familiar with Perl and could use some help.

I need to have the page "myPage.cgi?cnt=60" redirect to
"myPage.aspx?cnt=60". Can anyone give me an easy script for doing this
redirect?

Thanks for any help you can offer.

-Damon

 

[Matt Garrish]

Hi all,

I'm not very familiar with Perl and could use some help.

I need to have the page "myPage.cgi?cnt=60" redirect to
"myPage.aspx?cnt=60". Can anyone give me an easy script for doing this
redirect?

Assuming that is the only variable you're expecting, you could use the
following in myPage.cgi:

use strict;
use warnings;
use CGI;

my $q = new CGI;

my $cnt = $q->param('cnt');

print $q->redirect("http://wherever/myPage.aspx?cnt=$cnt");


Matt

 

[Damon]

Thanks Matt,

My only problem now is that this is all happening on a windows server.
The code you provided doesn't seem to work in this environment. I just
get the following error: "%1 is not a valid Win32 application."

You see, we have several links hard-coded into our desktop application
like "http://www.mydomain.com/myPage.cgi?cnt=50" which now need to
point to "http://www.mydomain.com/myPage.aspx?cnt=50".

Is there any way to make myPage.cgi?cnt=50 redirect and preserve the
querystring on a windows server?

-Damon

 

[Matt Garrish]

"Matt Garrish" <[email protected]> wrote in message

Whoa! Isn't this _precisely_ the sort of situation where CGI.pm is
overkill? After all, all this takes is regex substitution on a cgi
environment variable:

$ENV{REQUEST_URI} =~ s/myPage.cgi/myPage.aspx/;
$redirect = "http://" . $ENV{HTTP_HOST} . "/" . $ENV{REQUEST_URI};
print "Content-type: text/html\n\n";
print "Location: $redirect";

Uh, why are you sending an html content-type header? You do realize that
you're just going to print the new url to the browser, right?

More to the point, though, you're assuming that those variables are
available. In his follow-up post he mentions he's on a Windows server, and
IIS does not recognize REQUEST_URI. Another reason to push people in the
direction of CGI.pm over hand-rolled "solutions"... : )

Matt

 

[Gunnar Hjalmarsson]

Is there any way to make myPage.cgi?cnt=50 redirect and preserve the
querystring on a windows server?

I don't understand why Matt's suggestion would not work on Windows.
Anyway, as long as the key and value only consist of ASCII characters,
this should be sufficient:

print 'Location: http://www.mydomain.com/myPage.aspx?',
"$ENV{QUERY_STRING}\n\n";

 

[Matt Garrish]

Thanks Matt,

My only problem now is that this is all happening on a windows server.
The code you provided doesn't seem to work in this environment. I just
get the following error: "%1 is not a valid Win32 application."

You see, we have several links hard-coded into our desktop application
like "http://www.mydomain.com/myPage.cgi?cnt=50" which now need to
point to "http://www.mydomain.com/myPage.aspx?cnt=50".

Is there any way to make myPage.cgi?cnt=50 redirect and preserve the
querystring on a windows server?

<please don't top-post>

The script I provided should work regardless of what value of cnt is passed
to it. The error you note sounds like it's in the way that you have the .cgi
extension mapped. Do any .cgi scripts work on your server?

Matt

 

[John Bokma]

Whoa! Isn't this _precisely_ the sort of situation where CGI.pm is
overkill? After all, all this takes is regex substitution on a cgi
environment variable:

$ENV{REQUEST_URI} =~ s/myPage.cgi/myPage.aspx/;

Um... if my URI is eh... myP%61ge.cgi?

and why are you rewriting myPagescgi to myPage.aspx?

 

[raymond]

Should not be sent content-type for redirection so need this line for below example

print "Content-type: text/html\n\n"; **no need


raymond raj

 

[John Bokma]

Should not be sent content-type for redirection so need this line for below example

print "Content-type: text/html\n\n"; **no need


raymond raj

If you don't top-post, it's more easy to reply for you, and for us to
understand.

 

[Alan J. Flavell]

Should not be sent content-type for redirection

Wrong. RTFRFC. This is off-topic for a Perl language group so I'll
say no more about that. Discerning usenauts know that anything posted
in TOFU format needs to be distrusted.

 

[Joe Smith]

$ENV{REQUEST_URI} =~ s/myPage.cgi/myPage.aspx/;
$redirect = "http://" . $ENV{HTTP_HOST} . "/" . $ENV{REQUEST_URI};
print "Content-type: text/html\n\n";
print "Location: $redirect";

You've got the newlines in the wrong location.

$ENV{REQUEST_URI} =~ s/myPage\.cgi/myPage.aspx/;
$redirect = "http://" . $ENV{HTTP_HOST} . "/" . $ENV{REQUEST_URI};
print <<EOM;
Location: $redirect
Content-type: text/html

<html><body>Your browser should have automatically gone to
<a href="$redirect">$redirect</a></body></html>
EOM

-Joe

 

[Woody PurlGurl IV]

Uh, why are you sending an html content-type header? You do realize that
you're just going to print the new url to the browser, right?

Just a little cargo cult code to make you feel at home. Let's see,
what's worse, one needless line, or including a 100K library
needlessly?

More to the point, though, you're assuming that those variables are
available. In his follow-up post he mentions he's on a Windows server, and
IIS does not recognize REQUEST_URI. Another reason to push people in the
direction of CGI.pm over hand-rolled "solutions"... : )

Baloney. Trust me, there are cgi-environment variables on Windows
that should do the trick. Knowing them and/or knowing how to find
them is a _good_thing_.

Although others beside you have correctly criticized my code in parts,
_nobody_ else has defended your needless use of CGI.pm. In particular
I like Gunnar's solution:

print 'Location: http://www.mydomain.com/myPage.aspx?',
"$ENV{QUERY_STRING}\n\n";

Note the similarity of concept to my conception. The "ayes" have it

 

[Matt Garrish]

Baloney. Trust me, there are cgi-environment variables on Windows
that should do the trick. Knowing them and/or knowing how to find
them is a _good_thing_.

Although others beside you have correctly criticized my code in parts,
_nobody_ else has defended your needless use of CGI.pm. In particular
I like Gunnar's solution:

Why would anyone post a defense of a working solution? And why provide
someone a non-working and non-portable solution as you attempted to do? I
see your alter-ego is just as out-to-lunch as the original.

Matt

 

[Alan J. Flavell]

Try reading this group for a while. Lurk before you leap.

Why would anyone post a defense of a working solution? And why provide
someone a non-working and non-portable solution as you attempted to do? I
see your alter-ego is just as out-to-lunch as the original.

Looks that way to me, too.

As for the history of Gunnar recommending solutions which bypass
CGI.pm, the relevant discussions from past exchanges can be consulted
at the usual news archives. I don't see any benefit in going over
them yet again.

 

[Gunnar Hjalmarsson]

As for the history of Gunnar recommending solutions which bypass
CGI.pm, the relevant discussions from past exchanges can be
consulted at the usual news archives.

Even if I disagree on your using of the word "bypass", I won't argue
this time.

I don't see any benefit in going over them yet again.

That's fair. So, why did you refer to them in the first place? If you
disapprove of the suggestion I posted in this thread, wouldn't it have
been more suitable to say so?

 

[Alan J. Flavell]

That's fair. So, why did you refer to them in the first place?

To encourage anyone who's seriously interested to go and check a news
archive, if they haven't already done so.

If you disapprove of the suggestion

My views are more complex than that, as I thought I had made clear
before. But I don't want to get involved in troll-feeding again:
you are sufficiently acquainted with the climate around here to work
out for yourself whether you want to get dragged-in or not, and I've
really said all that I thought it worthwhile to say.

good luck.

 

[Damon]

<please don't top-post>

The script I provided should work regardless of what value of cnt is passed
to it. The error you note sounds like it's in the way that you have the .cgi
extension mapped. Do any .cgi scripts work on your server?

Matt

Hi all,

Sorry about the top-posting.

Thanks to all for your help. Both Matt and Gunnar's solutions solved
my problem. I found out that the Windows server I am hosted on was not
correctly setup to process CGI. Once this was fixed, both scripts
worked.

Thanks for all your help! I really appreciate it...

-Damon

 

[Woody PurlGurl IV]

Why would anyone post a defense of a working solution? And why provide
someone a non-working and non-portable solution as you attempted to do?

Its called a "trade-off". Your approach may be portable, but for this
one-off script the performance cost of using CGI.pm is unnecessary,
and depending on volume, perhaps even prohibitive. And certainly
avoidable.

Discussions in this group occasionally concede that using CGI.pm may
not always be necessary. This in my opinion is a perfect scenario.
Why load literally 1000 times more code than necessary (100 K vs 100
bytes, give or take)?

I see your alter-ego is just as out-to-lunch as the original.

A) Of course this must be PurlGurl's alter ego. After all, PurlGurl
is the only person on planet earth that ever uses the phrase "cargo
cult". Oops, except for the compilers of foldoc, apparently.

B) You are the one who is "out to lunch" if you are not willing to
concede even the _possibility_ of a valid trade-off in this scenario.

 

[Matt Garrish]

Its called a "trade-off". Your approach may be portable, but for this
one-off script the performance cost of using CGI.pm is unnecessary,
and depending on volume, perhaps even prohibitive. And certainly
avoidable.

Based on what fact? Both mod_perl and aspx scripts only need to compile once
(and with mod_perl you can precompile the modules). You need to find a
better argument.

Discussions in this group occasionally concede that using CGI.pm may
not always be necessary. This in my opinion is a perfect scenario.
Why load literally 1000 times more code than necessary (100 K vs 100
bytes, give or take)?

I never said it was the only way. You jumped at the chance to trash CGI.pm
and posted some garbage. I pointed out you were wrong. I never said anything
to the people who posted workable solutions.

Matt

 

[Gunnar Hjalmarsson]

Both mod_perl and aspx scripts only need to compile once (and with
mod_perl you can precompile the modules).

Don't take for granted that mod_perl is an available option. The OP in
this thread used the wording "the Windows server I am hosted on".