CGI "working" message/page ?

[- Bob -]

Question about CGI... maybe a header I should know more about (?).

At some sites, when you start a transaction such as placing an order
or processing a credit card (which may take a bit of physical time)
you get a "working" message of some sort that hangs around for a
while, then the results appear.

What I am wondering about is how they do this "dual" output -
apparently sending you one web page, then sending you another without
ending the transaction. I can think of some really sloppy ways of
doing this with a refresh, but I get the impression that they are
doing this through some other mechanism I don't know about.

Is there some way to send the browser some output, keep the connection
open, then send a "clear window" instruction and then send the final
page?

Insight appreciated.

 

[Jürgen Exner]

Question about CGI... maybe a header I should know more about (?).

At some sites, when you start a transaction such as placing an order
or processing a credit card (which may take a bit of physical time)
you get a "working" message of some sort that hangs around for a
while, then the results appear.

I bet this has nothing to do with Perl and neither with CGI. If at all I
would guess it's some HTTP property. That's were I would start looking if I
were you.

jue

 

[xhoster]

Question about CGI... maybe a header I should know more about (?).

At some sites, when you start a transaction such as placing an order
or processing a credit card (which may take a bit of physical time)
you get a "working" message of some sort that hangs around for a
while, then the results appear.

What I am wondering about is how they do this "dual" output -
apparently sending you one web page, then sending you another without
ending the transaction.

There are many ways of doing it, most of which have nothing to do with
Perl. Have you tried looking at the html source of one of the pages you
find particularly nifty, and reverse engineering it?

Myself, I just use the <meta http-equiv="refresh" ....> tag. Sloppy though
some people may find it, it gets the job done.

Xho

 

[- Bob -]

Myself, I just use the <meta http-equiv="refresh" ....> tag. Sloppy though
some people may find it, it gets the job done.

What does the refresh do? Keep polling a program / data area looking
for some "program completed" data bit left by the process you are
waiting to have completed?

 

[Jamie]

Question about CGI... maybe a header I should know more about (?).

I guess it's sort of CGI related..

You can't do it. (with CGI)

At some sites, when you start a transaction such as placing an order
or processing a credit card (which may take a bit of physical time)
you get a "working" message of some sort that hangs around for a
while, then the results appear.

Seriously, even if you used Refresh, there is a problem.

If someone were to hit submit 5 times before the browser refreshed the page,
you would get 5 different form submissions. This can be a problem in some
cases (like credit card transactions)

The way to reliably do this is to have a javascript function disable the submit
button, then hide/swap the display and finally submit the form. In the "old"
days, they'd just grey out the submit button. These days, it's a simple matter
of using DHTML. (Javascript DOM, it sounds hard but it's really easy, AJAX
isn't even needed)

I tried once to solve this w/out javascript, using perl and lock ID's, etc..
no matter what I did there was the lag between "submit", the servers
realization of "submit" and people who were committed to racking up a dozen
charges on their card within the second or so it took the server to respond.

Far as I know, this just can't be done in CGI.

Jamie

 

[Keith Keller]

What does the refresh do? Keep polling a program / data area looking
for some "program completed" data bit left by the process you are
waiting to have completed?

Refresh is not Perl. You should ask in an HTML group. (Or better
still, look for docs on the web or in books--the behavior of the refresh
meta tag is well-documented.)

--keith

 

[Henry Law]

What does the refresh do?

A little advice. You could have answered that question yourself, so
asking it here looks like laziness. The clever Perl people (i.e. not
me) are really clever, but also really busy, and laziness isn't attractive.

And if you'd answered the question you'd also have found the other
aspect, which is that "refresh" has nothing to do with Perl (and
everything to do with HTML and how browsers handle it), so there'd be no
point in posting it here anyway.

Read this; it will help: http://www.catb.org/~esr/faqs/smart-questions.html

 

[Derek.Moody]

In <09c8131jsaj1kjmmtggablp7g2vqqff3ov@4ax.com>,
- Bob - <uctraing@ultranet.com> mentions:

I guess it's sort of CGI related..

You can't do it. (with CGI)

You can't do it -as requested- with CGI

The way to reliably do this is to have a javascript function disable the submit

And you can't rely on javascript being enabled.

I tried once to solve this w/out javascript, using perl and lock ID's, etc..
no matter what I did there was the lag between "submit", the servers

If you keep the page *simple* (no tables/frames/lists/nested structures)
then every browser I have tried it on is able to display partial output:

use strict;
use CGI qw/:standard/;

$|=1; # autoflushing on

print header(),start_html('Slow Page'),p('Please Wait');

do_something_time_consuming();

print p('Done.');

show_results();

print end_html;


Hth. Cheerio,

--

 

[J. Gleixner]

You can't do it -as requested- with CGI


And you can't rely on javascript being enabled.


If you keep the page *simple* (no tables/frames/lists/nested structures)
then every browser I have tried it on is able to display partial output:

use strict;
use CGI qw/:standard/;

$|=1; # autoflushing on

print header(),start_html('Slow Page'),p('Please Wait');

do_something_time_consuming();

print p('Done.');

show_results();

print end_html;


Hth. Cheerio,

No, the HTTP connection will likely time out on more time consuming tasks.

For a more proper solution, see:
http://www.stonehenge.com/merlyn/WebTechniques/col20.html

 

[xhoster]

No, the HTTP connection will likely time out on more time consuming
tasks.

Just doing an occasional print will take care of that, in my experience
(which is on apache server with both firefox and IE browsers).

If you can't control the time-consuming part so that print occasionally,
I've found that this usually works:

$|=1; ## if not already
{
local $SIG{ALRM}= sub { print ".\n"; alarm 10 };
alarm 10;
do_something_time_consuming();
alarm 0;
}

For a more proper solution, see:
http://www.stonehenge.com/merlyn/WebTechniques/col20.html

I agree that that is a nice solution, but sometimes it is over-kill.

Xho