
So if your 7z file is being served with a content type like "text/html" or "text/plan" that is one FFox knows to try to display, you'll get the results you describe. MSIE, on the other hand, ignores the http standards, ignores the http header content-type, and takes its own best guess on how to handle the file - consequently many server admins aren't even aware of the problem if they are serving the files with the wrong content type. If a file is served with a content type that isn't automatically displayed or handled by FFox, it will ask you what to do with the file. Sometimes the server housing the file in question may not be configured correctly and delivers an http response header with an incorrect content type. 7z files should have content type "application/x-7z-compressed".executable files will have content type "application/octet-stream" or one more specific to the application.plain text files should have content type of "text/plain".Html should have content type of "text/html".Here are some common content types (there are many more):

It is the responsibility of the server housing the files to send an appropriate content-type in the http response header. It is this content-type in the response header (NOT the filename extension) that a standards-compliant browser like FFox uses to determine how to handle the file. One of the functions of the http response header is to define what type of file is attached, via a "content-type" (often referred to as MIME type) declaration - this tells the browser how to handle the file.

NOTE: this is in addition to any statements included in the section of an actual html document.īrowsers handle the reception of the response header transparently so the general user is not aware of it.

The system at the other end evaluates the request, then sends back an http response header attached to the return file. When you click on a link, your browser sends an http request.
