CGI Redirect to another page

[Andrew Chalk]

In a Python script running under CGI, can I programatically redirect the
program to another page. Assume that I have a static HTML page that I want
displayed (e.g. index.htm). Other than 'print ...' is there any way to
redirect to this URL (for example, like Response.Redirect() in ASP)?

Many thanks.

 

[Andrew Dalke]

Andrew Chalk:

Assume that I have a static HTML page that I want
displayed (e.g. index.htm). Other than 'print ...' is there any way to
redirect to this URL (for example, like Response.Redirect() in ASP)?

The Response.Redirect likely works by putting something in
the header. The HTML page you have doesn't have access to
the header. However, you can use the meta tag to tell the
browser to look elsewhere. But that won't work for tools which
don't parse the HTML.

It's an easy web search (once you know the right keywords -
"header redirect meta" and I found
http://vancouver-webpages.com/META/FAQ.html#redirect
"How can I redirect the user to another page ?"
with three different answers

Andrew
(e-mail address removed)

 

[Tim Howarth]

In message <[email protected]>

In a Python script running under CGI, can I programatically redirect the
program to another page.

Do you mean redirect the client browser ?

Assume that I have a static HTML page that I want displayed (e.g.
index.htm). Other than 'print ...' is there any way to redirect to this
URL (for example, like Response.Redirect() in ASP)?

Assuming you mean not to print the whole page, when you say "Other than
'print ...'" then;

print "Location: http:abcxyz.index.html"

AFAIUI it simply sends a redirect header.

 

[Tim Howarth]

In message <[email protected]>

In message <[email protected]>


print "Location: http:abcxyz.index.html"

Or even a properly formed URL !

 

[Andrew Chalk]

Thanks, good web search! I couldn't get "Location:URL" to work but META did.

Regards.

 

[Andrew Clover]

print "Location: http://abcxyz/index.html"

AFAIUI it simply sends a redirect header.

Yep; however, if you include a relative URI with no hashpart:

print 'Location: /index.html'
print

Then the server should send that page to the browser directly, without
sending a redirect back to the browser. This may be preferable in
some cases.

(The second print is needed to end the CGI response headers.)

Full spec here:

http://hoohoo.ncsa.uiuc.edu/cgi/interface.html

(Using JavaScript or meta-refresh to do redirects is almost always a
really terrible idea.)

 

[Tom Anderson]

In a Python script running under CGI, can I programatically redirect the
program to another page. Assume that I have a static HTML page that I
want displayed (e.g. index.htm). Other than 'print ...' is there any way
to redirect to this URL (for example, like Response.Redirect() in ASP)?

you have two options:

- write a Location header; the web server will notice it and spit out the
file you specify

- write Status and Location headers, giving status 302 (or 303); the web
server will notice the Status header and give the client the appropriate
status code; the client will then follow the redirect you give it in the
Location header

see:

http://hoohoo.ncsa.uiuc.edu/cgi/out.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

tom

 

[John J. Lee]

(Using JavaScript or meta-refresh to do redirects is almost always a
really terrible idea.)

I know I don't like them "on principle", but what practical problems
do they cause? Do proper HTTP redirects avoid the "back button trap",
maybe? I've never noticed...


John

 

[Andrew Chalk]

What is wrong with meta-refresh?

Yep; however, if you include a relative URI with no hashpart:

print 'Location: /index.html'
print

Then the server should send that page to the browser directly, without
sending a redirect back to the browser. This may be preferable in
some cases.

(The second print is needed to end the CGI response headers.)

Full spec here:

http://hoohoo.ncsa.uiuc.edu/cgi/interface.html

(Using JavaScript or meta-refresh to do redirects is almost always a
really terrible idea.)

 

[Erik Max Francis]

What is wrong with meta-refresh?

The use of the Location header is much more direct.

 

[Alan Kennedy]

[Andrew Chalk wrote]

What is wrong with meta-refresh?

It is claimed that search engines treat meta-refresh with suspicion. I
don't know if this is true or not. The following article (as an
example, this is just the first link I found when googling for "abuse
meta refresh"), claims that Altavista bans sites that use a meta
refresh period below 30 seconds.

META Refresh And Search Engines
http://www.netmechanic.com/news/vol4/promo_no15.htm

regards,

 

[Andrew Clover]

I know I don't like them "on principle", but what practical problems
do they cause? Do proper HTTP redirects avoid the "back button trap",
maybe?

Yes, they do. They are also more widely supported by robots (including
search engine spiders) and older and non-desktop browsers (as well as
newer browsers which can have meta-refresh and/or JavaScript disabled).

An HTTP redirect is an unequivocal statement that a resource is elsewhere,
at a transport level. It can be understood and acted on by agents with no
knowledge of HTML or JavaScript (for example Python's urllib), and can
potentially be used to automatically update links.

Meta-refresh (or, less commonly used, Refresh as an HTTP header) was
designed for re-fetching pages that update themselves, such as webcams.
It's still useful for this, although it has yet to be standardised.

Using meta-refresh or JavaScript for a redirect is really a misuse,
and is needed only:

a. When you need to set a cookie at the same time as doing a redirect.
Some browsers will not allow a cookie to be set in anything but a
'200 OK' response.

b. When your web hosts are exceedingly crappy and don't allow you to
do proper redirects through server config or CGI.

In these cases I prefer to use JavaScript's location.replace() method (which
also avoids the back button trap), combined with a short-delay meta-refresh
as backup and a plain HTML link in the returned page as backup for the
backup (for robots etc).

It is claimed that search engines treat meta-refresh with suspicion.
I don't know if this is true or not.

It's not easy to tell, but Google is known to have 'anti-cloaking' measures
for detecting search engine abuse. Since meta-refresh is commonly used for
sending browsers to a different page than engines, it is possible that
a meta-refresh - likely combined with other indicators Google could find
suspicious - might result in a PR0 block.

More importantly, many robots won't follow a meta-refresh at all. (After all,
they don't want to end up following an infinitely refreshing webcam page.)
So a backup <a> link should always be included.