By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,057 Members | 1,401 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,057 IT Pros & Developers. It's quick & easy.

html to ftp redirection not working

P: n/a
Hi there,
I am using a perl script to generate this html page which just
redirects users to my ftp server. The problem is I get a "page cannot
be displayed" in IE 6.0 (haven't tried other browsers) when the
redirection happens. But the redirection happens to the correct ftp
location and on pressing "Refresh" the FTP login dialog bar appears
and everything is fine.

Here is the HTML in question.

<HTML>
<HEAD>
<META http-equiv='REFRESH' content = '3; URL =
ftp://192.168.0.11'>
<TITLE>FTP Data</TITLE>
</HEAD>
<BODY>
<p>You are being redirected to ftp://192.168.0.11 in 3 seconds</p>
</BODY>
</HTML>

and the perl file that generates the html is

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "<HTML><HEAD>";
print "<META http-equiv='REFRESH' content = '3; URL =
ftp://$ENV{'HTTP_HOST'}'>";
print "<TITLE>FTP Data</TITLE>";
print "</HEAD><BODY>";
print "<p>";
print "You are being redirected to ftp://$ENV{'HTTP_HOST'} in 3
seconds";
print "</p>";
print "</BODY></HTML>"

Can anyone tell me how to deal with this glitch? Thanks in advance.
-Manu
Jul 20 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Manu wrote:
Hi there,
I am using a perl script to generate this html page which just
redirects users to my ftp server. The problem is I get a "page cannot
be displayed" in IE 6.0 (haven't tried other browsers) when the
redirection happens. But the redirection happens to the correct ftp
location and on pressing "Refresh" the FTP login dialog bar appears
and everything is fine.

Here is the HTML in question.

<HTML>
<HEAD>
<META http-equiv='REFRESH' content = '3; URL =
ftp://192.168.0.11'> [...] Can anyone tell me how to deal with this glitch? Thanks in advance.


Yes, rewrite the Perl script that instead issues a real HTTP redirect
instead of quasi-standard <meta http-equiv> junk. IE, as well as real Web
browsers, should handle this much better.

--
Shawn K. Quinn
Jul 20 '05 #2

P: n/a
Manu wrote:
this html page which just redirects users to my ftp server.
Why don't you just provide a link to the ftp server? Are users incapable
of following a link?
The problem is I get a "page cannot be displayed" in IE 6.0 (haven't
tried other browsers) when the redirection happens. But the
redirection happens to the correct ftp location and on pressing
"Refresh" the FTP login dialog bar appears and everything is fine.
IE/Win issues one set of accept headers when it tries a new url. But it
issues different accept headers when reloading (or "refreshing") the
url. It's very strange behavior. You can, apparently, edit what accept
headers IE sends by editing the Windows registry. I've never been brave
enough to try that, perhaps because I've been frightened away by warning
messages.
<META http-equiv='REFRESH' content = '3; URL = ftp://192.168.0.11'>


Non-standard.

It seems to me that, if the page is merely an intermediary step to the
content, then a server redirect with proper response code, is
appropriate. But if you don't want to send www ua's to an ftp server
without the user's explicit knowledge -- that would be best in my view
-- then a simple link would be best.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #3

P: n/a
Shawn K. Quinn wrote:
Manu wrote:
I get a "page cannot be displayed" in IE 6.0 (haven't tried other
browsers) when the redirection happens. But the redirection happens
to the correct ftp location and on pressing "Refresh" the FTP login
dialog bar appears and everything is fine.
The difference in the 2 responses is key, I think.
Here is the HTML in question.

<META http-equiv='REFRESH' content = '3; URL = ftp://192.168.0.11'>

rewrite the Perl script that instead issues a real HTTP redirect
instead of quasi-standard <meta http-equiv> junk.


Certainly good advice.
IE, as well as real Web browsers, should handle this much better.


If by real web browsers you mean those with appropriate (IMHO) accept
headers, then I agree, they will handle it better. (Though a text link
may still be preferable.)

IE/Win is another matter. I'm not sure what its accept headers will mean
for the ftp protocol. See also my first note in this thread for a brief
explanation.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #4

P: n/a
Manu wrote:
html page which just redirects users to my ftp server. The problem is
I get a "page cannot be displayed" in IE 6.0 (haven't tried other
browsers)

You probably should try other browsers. ;-)
ftp://192.168.0.11
I just tried that address in Mozilla 1.6/Win; operation timed out. Tried
it in MSIE 5.5/Win; the "browser" changed into an os thingy of some
sort; error, "Windows was unable to browse this folder." Looks like the
problem is server related.
when the redirection happens. But the redirection happens
to the correct ftp location and on pressing "Refresh" the FTP login
dialog bar appears and everything is fine.


Given the two different results in IE/Win, I'd have to think it has to
do with the change in accept headers. But then, on reflection, I don't
know how MSIE/Win reacts to an ftp server, and I don't have the means to
test it. Apologies if my earlier post turns out to be a red herring.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #5

P: n/a
Brian <us*****@julietremblay.com.invalid> wrote in message news:<10*************@corp.supernews.com>...
Given the two different results in IE/Win, I'd have to think it has to
do with the change in accept headers. But then, on reflection, I don't
know how MSIE/Win reacts to an ftp server, and I don't have the means to
test it. Apologies if my earlier post turns out to be a red herring.


Does the FTP protocol even use "accept headers"?

--
Dan
Jul 20 '05 #6

P: n/a
Daniel R. Tobias wrote:
Brian wrote...
Given the two different results in IE/Win, I'd have to think it has
to do with the change in accept headers. But then, on reflection, I
don't know how MSIE/Win reacts to an ftp server, and I don't have
the means to test it. Apologies if my earlier post turns out to be
a red herring.


Does the FTP protocol even use "accept headers"?


I don't know, but when the question is posed so bluntly, it seems like
the answer is no. Why would it? How would it? It makes no sense. The
more I think about it, the more I think my initial response was barely
half-baked. My apologies. The change on reload sent me running in the
wrong direction. (I was unable to connect using Mozilla, as well as IE,
so it perhaps the op was seeing nothing more than an unresponsive server.)

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #7

P: n/a
Brian <us*****@julietremblay.com.invalid> wrote
Why don't you just provide a link to the ftp server? Are users incapable
of following a link?
In the end thats what I did. The problem really happened when the web
+ FTP server was configured to DHCP (from a static IP) in our
intranet. Originally I had a link from index.htm to
ftp://staticIPofTheServer as the FTP link. When the server moved to
DHCP I thought I could just change the link to point to ftp.pl which
then redirects it to the FTP server. Also I didn't want users follow 2
links instead of just 1 to get to the FTP server. Now I have my
index.htm with an IFRAME (links.pl) which generates the correct FTP
link and solved the problem.

You probably should try other browsers. ;-)
I use linux/mozilla and the command prompt to FTP, but 90% of my
office uses IE6.0 and don't like change.

I just tried that address in Mozilla 1.6/Win; operation timed out. Tried
it in MSIE 5.5/Win; the "browser" changed into an os thingy of some
sort; error, "Windows was unable to browse this folder." Looks like the
problem is server related.


Thats because you are not inside my intranet. Thats a class C IP
address. Its not a globally unique IP and is only used inside
intranets.
Thank you all for your advice and helping me work around this problem.
I would still be interested in knowing what the real problem was.
Jul 20 '05 #8

P: n/a
Manu wrote:
Brian wrote
I just tried that address in Mozilla 1.6/Win; operation timed out.
Thats because you are not inside my intranet.


You might have mentioned that in your op, saved me (and probably others)
some time.
Thank you all for your advice and helping me work around this problem.
I would still be interested in knowing what the real problem was.


Without a url accessible to us, I have no way of investigating any further.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/
Jul 20 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.