Hi all!

In my menu buttons is a button called Manual. The link is "prg/krs.exe" This link works using the "Test in Browser" button and works by going through the File menu in the browser, i.e. d:\CBnews\default.htm, but when I go to the actual webpage, http://homebase/cbnews, a Http error 404 occurs and it says it cannot find the page. If I change the link to "prg/krs.txt", it has no trouble finding the page no matter how I access. Therefore I have 2 questions:
1. Why can't I find the page using http?
2. When it does find the page in test, it pops up a security warning about whether to run or save, then another security warning about the publisher. How do I set it to not display those warnings and go right to the manual?

Thanks for any and all help,

Jim

Jim,

You may want to click on profile and change your forum name to something other than your email address. Spammers are always looking for valid email addresses.

You give two different file names krs.exe and krs.txt. There are different ways of linking to a file. If you have a file link to file.txt, and you are at your home page, the browser will look for the file at http://www.yoursite.com/file.txt. Now if you give that file as files/file.txt, I think it is looking in your root directory for a file with a slash / in the name. If you want to look in a file named files, use either the entire link of http://www.yoursite.com/files/file.txt, or you can use a relative link of /files/file.txt.

If you can provide a link to the problem, someone here can take a look and tell you what is causing the problem.

billr,

Thanks for the heads up on the name thing. However, I fear I did not explain the situation right. Let me try this again.

The site is an intranet. It is based on server called let's say home. The website is on a logical drive in a folder named and shared as news. Therefore to access http://home/news/default.htm. I use subfolders of news to store various types of docs, hence the link address for a menu button of prg/krs.exe, my problem child. The other file krs.txt was put into the prg subfolder as a test file only. On my computer, this site performs correctly using the test in browser feature of CoffeeCup, the krs.exe runs and opens up the manual as intended. I moved the site to home and used the above url to access. All worked correctly until I checked the menu button in question. The address bar read http://home/news/prg/krs.exe and the browser window was displaying File not found. I then clicked on File, clicked on Open and drilled down to d:/cbnews/default.html and again opened the site. Now it all worked again, the browser found the file d:/cbnews/prg/krs.exe and ran it. Back to using http://home/news/pgr/krs.exe and again no file. That is when I changed the address bar to krs.txt and the browser found it. That tells me the directory structure is okay, but why can't the file be found when using the http url?

Thanks,
Jim
Capt OG (other grandpa)

Again, let me clarify. The last question is referring to the exe file.

Do you actually have a web server like IIS or Apache running on the home server? I'd imagine that you can use http: links simply by sharing folders. With IIS, it's not really running as web site but rather just using IE's integration to allow file browsing. That would most likely also explain why you get the security warnings as if you're just trying to load the pages locally rather than through an actual web server. If you don't already have IIS set up, it's not too much trouble doing so (especially since your keeping it internal). I can try to help w/ that further if needed.

P.S. You mean to tell me Capt OG isn't short for Captain O.G. Readmore?

Hi Adam,

Thanks for the reply. Yes, I have IIS running on that server. I created a virtual directory called news and pointed it at the folder on the d: drive. I am wondering now if I would have more success moving the site instead into the normal c:/inetpub/wwww folder setup and just using http://homebase. I am wondering, does the http: protocol itself recognize the exe extension as it does pdf, txt, doc, etc.

Jim

Thanks to all who have pondered this. The answer seems to be to have my network users use file:// instead of http://. Don't know why that works, but I am not going to argue with success.

Jim