CGI redirection: let us discuss it further

[Sullivan WxPyQtKinter]

I am now programming python scripts for CGI environment. The
redirection has been discussed in this forum for over one hundred
times. I have seen most of them, but still have some questions:

1. Are there any method (in python of course) to redirect to a web page
without causing a "Back" button trap(ie, when user click the back
button on their web browser, they are redirect to their current page,
while their hope is probably to go back to the last page they have
seen, rather than the redirection page with a "Location: url" head and
blank content.)?

2. Are there any method to use relative path, rather than full absolute
URI path in "Location: url"? It is very essential for later transplant
work, e.g.,transplant a folder of cgi scripts from one web server to
another, with different URL.

Thank you.

[Sybren Stuvel]

Re: CGI redirection: let us discuss it further

Sullivan WxPyQtKinter enlightened us with:[color=blue]
> 1. Are there any method (in python of course) to redirect to a web
> page without causing a "Back" button trap(ie, when user click the
> back button on their web browser, they are redirect to their current
> page, while their hope is probably to go back to the last page they
> have seen, rather than the redirection page with a "Location: url"
> head and blank content.)?[/color]

I don't know if this is possible using CGI. I use CherryPy, and it has
an InternalRedirec t method. Same is true for mod_python and Apache.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[I V]

Re: CGI redirection: let us discuss it further

Sullivan WxPyQtKinter wrote:[color=blue]
> 1. Are there any method (in python of course) to redirect to a web page
> without causing a "Back" button trap(ie, when user click the back
> button on their web browser, they are redirect to their current page,
> while their hope is probably to go back to the last page they have
> seen, rather than the redirection page with a "Location: url" head and
> blank content.)?[/color]

I guess this may vary from browser to browser, but on Mozilla at least,
if your CGI script returns one of the 300 status codes, then the
redirect page doesn't get added to the browser history, and so the back
button works as expected.
[color=blue]
> 2. Are there any method to use relative path, rather than full absolute
> URI path in "Location: url"? It is very essential for later transplant
> work, e.g.,transplant a folder of cgi scripts from one web server to
> another, with different URL.[/color]

You don't have to use absolute URLs in a Location: header returned by a
CGI script. The web server will handle relative URLs for you. See the
CGI spec:

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

[Sybren Stuvel]

Re: CGI redirection: let us discuss it further

Dennis Lee Bieber enlightened us with:[color=blue]
> I suspect the desired function may be browser specific, since it
> sounds like one would need to "pop" a history record to remove the
> "redirect" page from the list...[/color]

That's only if you think from the browser's point of view. An internal
redirect goes unnoticed by the browser, hence there is no need for
such history manipulation. With an internal redirect there is no
"redirect page" at all, since the new URL is fetched from within the
server, and sent to the browser as the response to the requested URL.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[and-google@doxdesk.com]

Re: CGI redirection: let us discuss it further

Sullivan WxPyQtKinter wrote:
[color=blue]
> 1. Are there any method (in python of course) to redirect to a web page
> without causing a "Back" button trap... rather than the redirection page
> with a "Location: url" head[/color]

What's wrong with the redirection page?

If there's really a necessary reason for not using an HTTP redirect
(for example, needing to set a cookie, which doesn't work cross-browser
on redirects), the best bet is a page containing a plain link and
<script>-redirect, using location.replac e() to avoid the back button
trap.
[color=blue]
> 2. Are there any method to use relative path, rather than full absolute
> URI path in "Location: url"? It is very essential for later transplant
> work, e.g.,transplant a folder of cgi scripts from one web server to
> another, with different URL.[/color]

Just read the name of the server (os.environ['SERVER_NAME']) to work
out what absolute URL to redirect to, whist still being portable.

Here's some code I dug up that should also cope with non-default ports
and SSL, if that's of any use:

ssl= os.environ.get( 'HTTPS', 'off') not in ('', 'off', 'false', 'no')
scheme= ['http', 'https'][ssl]
port= ['80', '443'][ssl]
host= os.environ.get( 'SERVER_NAME', 'localhost')
url= '%s://%s:%s' % (scheme, host, os.environ.get( 'SERVER_PORT',
port))
if url.endswith(': '+port):
server= server[:-(len(port)+1)]
url+= path

(You *can* pass relative URLs back to the web server in a Location:
header, but this should do an internal redirect inside the server,
which may not be what you want.)

--
And Clover
mailto:and@doxd esk.com

http://www.doxdesk.com/

[Sullivan WxPyQtKinter]

Re: CGI redirection: let us discuss it further

[color=blue]
> Just read the name of the server (os.environ['SERVER_NAME']) to work
> out what absolute URL to redirect to, whist still being portable.
>
> Here's some code I dug up that should also cope with non-default ports
> and SSL, if that's of any use:
>
> ssl= os.environ.get( 'HTTPS', 'off') not in ('', 'off', 'false', 'no')
> scheme= ['http', 'https'][ssl]
> port= ['80', '443'][ssl]
> host= os.environ.get( 'SERVER_NAME', 'localhost')
> url= '%s://%s:%s' % (scheme, host, os.environ.get( 'SERVER_PORT',
> port))
> if url.endswith(': '+port):
> server= server[:-(len(port)+1)]
> url+= path
>
> (You *can* pass relative URLs back to the web server in a Location:
> header, but this should do an internal redirect inside the server,
> which may not be what you want.)[/color]


Sorry I do not quite understand what is the difference between an
internal redirection and an external one?[color=blue]
>
> --
> And Clover
> mailto:and@doxd esk.com
> http://www.doxdesk.com/[/color]

[Sybren Stuvel]

Re: CGI redirection: let us discuss it further

and-google@doxdesk. com enlightened us with:[color=blue]
> What's wrong with the redirection page?
>
> If there's really a necessary reason for not using an HTTP redirect
> (for example, needing to set a cookie, which doesn't work
> cross-browser on redirects), the best bet is a page containing a
> plain link and <script>-redirect, using location.replac e() to avoid
> the back button trap.[/color]

That's a very ugly hack. For starters, it requires much more traffic
than an internal redirect. Second, the URL changes, which might not be
wanted. Third, it requires JavaScript for something that can be done
without it.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Sybren Stuvel]

Re: CGI redirection: let us discuss it further

Sullivan WxPyQtKinter enlightened us with:[color=blue]
> Sorry I do not quite understand what is the difference between an
> internal redirection and an external one?[/color]

External:
- Browser requests URL A
- Server responds "Go to URL B"
- Browser requests URL B
- Server responds with contents of B
- Browser displays B

Internal:
- Browser requests URL A
- Server responds with contents of B
- Browser displays B

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Sullivan WxPyQtKinter]

Re: CGI redirection: let us discuss it further

Well, in that case, the internal direction is just what I need. Thank
you so much for help.