"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

" 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.

I suspect that it is this part that is going wrong, there is no association
for a .ez extension and the server is responding with a 404 error. Hence the
request for a MIME type.

Jeff

"Jeff" wrote in message
. com...

" 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.

I suspect that it is this part that is going wrong, there is no
association for a .ez extension and the server is responding with a 404
error. Hence the request for a MIME type.

Jeff



You could put it on the server as .EZ.bin and remove the bin from the name
when you dloaded from the server.

Jimmie

"Jeff" wrote in
. com:


" 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.

I suspect that it is this part that is going wrong, there is no
association for a .ez extension and the server is responding with a
404 error. Hence the request for a MIME type.

You obviously don't know how web servers, HTTP, and browsers work.

Owen

Owen Duffy wrote:
"Jeff" wrote in
I suspect that it is this part that is going wrong, there is no
association for a .ez extension and the server is responding with a
404 error. Hence the request for a MIME type.

You obviously don't know how web servers, HTTP, and browsers work.

Your ignorance and arrogance are showing again, Owen.
Jeff obviously knows exactly how Microsoft servers work.
--
73, Cecil http://www.w5dxp.com

On Wed, 09 May 2007 21:50:34 GMT, Cecil Moore
wrote:

Owen Duffy wrote:
"Jeff" wrote in
I suspect that it is this part that is going wrong, there is no
association for a .ez extension and the server is responding with a
404 error. Hence the request for a MIME type.

"web servers are configured to report a MIME type of text/plain
for unknown content types"

You obviously don't know how web servers, HTTP, and browsers work.

Your ignorance and arrogance are showing again, Owen.

And this is from someone who has never written a line of code for
desinging a server.

Jeff obviously knows exactly how Microsoft servers work.

So, the server is asking (which is what request means) the client for
the MIME type? What a yuk. And using M$ as the gold standard for
providing non-HTTP compliant servers? Yuk² Quite literally, M$ does
not know how HTTP servers are supposed to work.

"MIME is currently defined in RFCs 2045, 2046, 2047, 2048, and
2049 and registered values for MIME types are available in IANA |
MIME Media Types. The HTTP specification defines a superset of
MIME which is used to describe the media types used on the web."

M$ does not conform.

Source:
http://developer.mozilla.org/en/docs...ver_MIME_Types

From one who has written many servers - myself.

Richard Clark wrote:
And this is from someone who has never written a line of code for
desinging a server.

It would never occur to me that a line of code to make
a server stop singing was required. How did you stumble
upon that pressing need?
--
73, Cecil http://www.w5dxp.com

On Wed, 09 May 2007 22:23:06 GMT, Cecil Moore
wrote:

How did you stumble
upon that pressing need?

Only a pants-presser would be worried about that.

Richard Clark wrote in
:

....
Jeff obviously knows exactly how Microsoft servers work.

So, the server is asking (which is what request means) the client for
the MIME type?

I doubt it.

What a yuk. And using M$ as the gold standard for
providing non-HTTP compliant servers? Yuk² Quite literally, M$ does
not know how HTTP servers are supposed to work.

"MIME is currently defined in RFCs 2045, 2046, 2047, 2048, and
2049 and registered values for MIME types are available in IANA |
MIME Media Types. The HTTP specification defines a superset of
MIME which is used to describe the media types used on the web."

While some are stressing about getting IANA registration of the ez
extension, it already is, and to another application, and its type is
application/andrew-inset.

So, many web servers (using the IANA MIME media type list) will serve the
file up with a HTTP Content-Type of application/andrew-inset . That won't
affect most users, because their browser will not have any defined action
for that application type.

On a good web server, one could override that MIME association for the
file, files, directory or tree... but it shouldn't be necessary.

Owen

Owen Duffy wrote:
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.

Absolutely not the former. Apparently, Microsoft servers are
sensitive to filename extensions and must be told what to
do with each and every new type or else they get ignored
"as if" they were not there.
--
73, Cecil http://www.w5dxp.com