IE Perl problem

I've be writing wep pages in perl for about 4 or so years now and you think
I'd be able to solve this problem in that time.....

I have a frame with a menu in it (generated in perl)
I click a link to a perl script and it works fine, however, if I click it
again or another one for some reason the script doesn't execute it just
tells IE to download it to the client. this doesn't happen if I refresh the
links page. ....but it gets worse.... I click the link, it goes to the page
that lists a bunch of stuff, if I try to hit a perl link there or submit a
form that used perl it tries to download it again, if I clear the temp files
in IE it'll work one more time.
persoanlly it has me stumped, in my mind perl is serverside so the client
cache shouldn't make a difference should it? or do I have the theory of how
it works completely wrong?
let me know if anyone has had this prob and solved it or if you have any
ideas, thanks

Kiasanth M'Dra

In article <3fc6b801$0$13984$afc38c87@news.optusnet.com.au>, Kiasanth M'Dra wrote:
>I've be writing wep pages in perl for about 4 or so years now and you think
>I'd be able to solve this problem in that time.....
>
>I have a frame with a menu in it (generated in perl)
>I click a link to a perl script and it works fine, however, if I click it
>again or another one for some reason the script doesn't execute it just
>tells IE to download it to the client. this doesn't happen if I refresh the
>links page. ....but it gets worse.... I click the link, it goes to the page
>that lists a bunch of stuff, if I try to hit a perl link there or submit a
>form that used perl it tries to download it again, if I clear the temp file
s
>in IE it'll work one more time.
>persoanlly it has me stumped, in my mind perl is serverside so the client
>cache shouldn't make a difference should it? or do I have the theory of how
>it works completely wrong?
>let me know if anyone has had this prob and solved it or if you have any
>ideas, thanks

I wonder if this is anything like the experience I had with IE 5.5.

I have a product that I wrote that is a generic CGI gateway that will store
XML output of cookies and CGI data to file, and execute a configurable list
of commands based on which "program set" label is in the onegate_set
form field.  It has all the usual security bells and whistles.  It also
allows you to set what MIME type your output file is sent as.

Well during testing, I used the following commands in the set:
# Copy XML data input to output file so we see the generated XML.
cat %i > %o
# Set MIME type to XML
echo "text/xml" >%t

And it worked fine.  But here's the weird thing...  Once I'd submit that
form, during testing (long since completed) there were sometimes problems,
and I'd get the HTML error page from IE.  But when I corrected the problem,
it would receive the data, but try to output it as HTML, even though it had
the text/xml MIME type.  If I closed IE and restarted it, and submitted the
same identical data with no server-side changes, it would display the XML
as it should have originally.

IE seems flaky about MIME type changes from the same URL in the same
session.  It's not a solution, but it sounds -remarkably- similar to your
experiences--enough so that I thought I'd share them as at least a partial
validation that you're not alone.

--
Vorxion - Member of The Vortexa Elite

I have seen problems like that many times! Not all erors are caught by a web
server. Sometimes it's just a   ;   left out. Run the program on your own
computer (not on the server) just as a program. It will show you the error.

Al

web-site-builder.com

"Vorxion" <vorxion@knockingshopofthemind.com> wrote in message
news:3fc6d77a$1_1@news.iglou.com...
> In article <3fc6b801$0$13984$afc38c87@news.optusnet.com.au>, Kiasanth
M'Dra wrote: 
think 
the 
page 
a 
files 
how 
>
> I wonder if this is anything like the experience I had with IE 5.5.
>
> I have a product that I wrote that is a generic CGI gateway that will
store
> XML output of cookies and CGI data to file, and execute a configurable
list
> of commands based on which "program set" label is in the onegate_set
> form field.  It has all the usual security bells and whistles.  It also
> allows you to set what MIME type your output file is sent as.
>
> Well during testing, I used the following commands in the set:
>      # Copy XML data input to output file so we see the generated XML.
>      cat %i > %o
>      # Set MIME type to XML
>      echo "text/xml" >%t
>
> And it worked fine.  But here's the weird thing...  Once I'd submit that
> form, during testing (long since completed) there were sometimes problems,
> and I'd get the HTML error page from IE.  But when I corrected the
problem,
> it would receive the data, but try to output it as HTML, even though it
had
> the text/xml MIME type.  If I closed IE and restarted it, and submitted
the
> same identical data with no server-side changes, it would display the XML
> as it should have originally.
>
> IE seems flaky about MIME type changes from the same URL in the same
> session.  It's not a solution, but it sounds -remarkably- similar to your
> experiences--enough so that I thought I'd share them as at least a partial
> validation that you're not alone.
>
> --
> Vorxion - Member of The Vortexa Elite

Thanks, at least I know it's not just me
:)

"Vorxion" <vorxion@knockingshopofthemind.com> wrote in message
news:3fc6d77a$1_1@news.iglou.com...
> In article <3fc6b801$0$13984$afc38c87@news.optusnet.com.au>, Kiasanth
M'Dra wrote: 
think 
the 
page 
a 
files 
how 
>
> I wonder if this is anything like the experience I had with IE 5.5.
>
> I have a product that I wrote that is a generic CGI gateway that will
store
> XML output of cookies and CGI data to file, and execute a configurable
list
> of commands based on which "program set" label is in the onegate_set
> form field.  It has all the usual security bells and whistles.  It also
> allows you to set what MIME type your output file is sent as.
>
> Well during testing, I used the following commands in the set:
>      # Copy XML data input to output file so we see the generated XML.
>      cat %i > %o
>      # Set MIME type to XML
>      echo "text/xml" >%t
>
> And it worked fine.  But here's the weird thing...  Once I'd submit that
> form, during testing (long since completed) there were sometimes problems,
> and I'd get the HTML error page from IE.  But when I corrected the
problem,
> it would receive the data, but try to output it as HTML, even though it
had
> the text/xml MIME type.  If I closed IE and restarted it, and submitted
the
> same identical data with no server-side changes, it would display the XML
> as it should have originally.
>
> IE seems flaky about MIME type changes from the same URL in the same
> session.  It's not a solution, but it sounds -remarkably- similar to your
> experiences--enough so that I thought I'd share them as at least a partial
> validation that you're not alone.
>
> --
> Vorxion - Member of The Vortexa Elite

Kiasanth M'Dra wrote:

> I've be writing wep pages in perl for about 4 or so years now and you
> think I'd be able to solve this problem in that time.....
>
> I have a frame with a menu in it (generated in perl)
> I click a link to a perl script and it works fine, however, if I click it
> again or another one for some reason the script doesn't execute it just
> tells IE to download it to the client. this doesn't happen if I refresh
> the links page. ....but it gets worse.... I click the link, it goes to the
> page that lists a bunch of stuff, if I try to hit a perl link there or
> submit a form that used perl it tries to download it again, if I clear the
> temp files in IE it'll work one more time.
> persoanlly it has me stumped, in my mind perl is serverside so the client
> cache shouldn't make a difference should it? or do I have the theory of
> how it works completely wrong?\
not if you client uses the client cache's copy of the script.
Try setting the timeout value in the header created by the perl script.  In
CGI.PM ->
print $query->header(-type=>'image/gif',
-status=>'402 Payment Required',
-expires=>'+3d',
-cookie=>$my_cookie,
-charset=>'UTF-7',
-attachment=>'foo.gif',
-Cost=>'$0.02');



-expires

Some browsers, such as Internet Explorer, cache the output of CGI scripts.
Others, such as Netscape Navigator do not. This leads to annoying and
inconsistent behavior when going from one browser to another. You can force
the behavior to be consistent by using the -expires parameter. When you
specify an absolute or relative expiration interval with this parameter,
browsers and proxy servers will cache the script's output until the
indicated expiration date. The following forms are all valid for the
-expires field:
+30s                              30 seconds from now
+10m                              ten minutes from now
+1h                               one hour from now
-1d                               yesterday (i.e. "ASAP!")
now                               immediately
+3M                               in three months
+10y                              in ten years time
Thu, 25-Apr-1999 00:40:33 GMT     at the indicated time & date

Set you -expires to 'now' and see if you script works corretly
> let me know if anyone has had this prob and solved it or if you have any
> ideas, thanks
>
> Kiasanth M'Dra

"Kiasanth M'Dra" <kiasanth@hotmail.com> сообщил/сообщила в новостях
следующее: news:3fc6b801$0$13984$afc38c87@news.optusnet.com.au...
> I've be writing wep pages in perl for about 4 or so years now and you
think
> I'd be able to solve this problem in that time.....
>
> I have a frame with a menu in it (generated in perl)
> I click a link to a perl script and it works fine, however, if I click it
> again or another one for some reason the script doesn't execute it just
> tells IE to download it to the client. this doesn't happen if I refresh
the
> links page. ....but it gets worse.... I click the link, it goes to the
page
> that lists a bunch of stuff, if I try to hit a perl link there or submit a
> form that used perl it tries to download it again, if I clear the temp
files
> in IE it'll work one more time.
> persoanlly it has me stumped, in my mind perl is serverside so the client
> cache shouldn't make a difference should it? or do I have the theory of
how
> it works completely wrong?
> let me know if anyone has had this prob and solved it or if you have any
> ideas, thanks
>
> Kiasanth M'Dra
>
>