"Jeff" wrote in
.com:

....

I think the problem is that when the user clicks on the hyperlink the
server does not know how to respond to a .EZ file extension. It
understands that the user wants to download a zip or bin file or
display an html file, but no one has told it what to do when asked for
an EZ, so it reports that the file is not there.

Apart from special processing specified for some files or file types
(extensions), the server just sends the document back in a response under
http headers (some of which may be chosen based on extension - MIME type
association in the server's config files.

The "action" on receiving a document is entirely in the hands of the
browser.

If the file ain't on the server, it ain't there and you will get a 404
error, and it ain't there either because is just ain't there, or it is
hidden by permissions that do not expose it to the server's user or
group.

Cecil stated that the HSP doesn't "process" the file, perhaps he is
hinting that he can't transfer the .EZ file into his web file space. If
that is so, he should visit whether his HSP is altogether too clever.

He seems like he is using a IIS server. I wonder why one would use an IIS
based server unless using IIS specific applications.

If I click on the link http://www.vk1od.net/7MDipole/7MDipole.ez on my
web server, Firefox asks me if I want to open it with EZNEC, use Flasgot,
or save it to disk. My web server does not know anything about the .ez
extension, and Firefox is not configured for any specific action for .ez
file. The reasons Firefox offers the "open with EZNEC" option is that it
digs into Windows to see if there is an open action defined for that
extension. Different browsers work differently.

If I click on Cecil's link, I get a 404 error: file not found which is a
strong indicator the file is not there, or has incorrect permissions,
probably the former.

Owen