IIS 6.0 and Firefox

I have IIS running on 2003 and Mozilla Firefox clients cannot properly browse the site.
When trying to access the url I get the dialog box
You have chosen to open
which is a: application/octet-stream
from: http://www.....
What should Firefox do with this file?
Open with....
Save to Disk

This only happens on my one web server.
If I use another 2003 server internally it does not have a problem
If I use my XP station which is IIS 5, there is no problem.
So it must be a config issue on my 2003 web server.

Re: IIS 6.0 and Firefox

It sounds like you configured a * MIME Type of "application/octet-stream" on
the IIS6 server or an application mapping that is returning that
Content-Type for the resource, all of which confuses the browser. Remove the
broken configuration and things should go back to normal.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"David Lewis" wrote in message
news:01fo41p8tl0c7djptcu3tmc8ml0sbmsjth@4ax.com...
I have IIS running on 2003 and Mozilla Firefox clients cannot properly
browse the site.
When trying to access the url I get the dialog box
You have chosen to open
which is a: application/octet-stream
from: http://www.....
What should Firefox do with this file?
Open with....
Save to Disk

This only happens on my one web server.
If I use another 2003 server internally it does not have a problem
If I use my XP station which is IIS 5, there is no problem.
So it must be a config issue on my 2003 web server.

Re: IIS 6.0 and Firefox

Hi David,

IIS does not look at the client used, so it does not send a different
response if it is IE or Firefox.

The problem seems to be that Firefox does not know what to do with the
file, and therefore asks the user what he/she want Firefox to do. You seem
to send a MIME type of application/octet-stream, and that seems to not be
correct (can't say for sure, because i do not know what kind of file it
is). But if this is a simple HTML file, you want to show up in the
browser, then for sure it is wrong MIME type.

The MIME type can also be customized by code (ASP.NET file for example),
which could be happen in your case.

I think however that this is a problem in your Firefox client. And after
all, it do work on other machines.


--
Regards,
Kristofer Gafvert
www.gafvert.info - My Articles and help
www.ilopia.com


David Lewis wrote:

> I have IIS running on 2003 and Mozilla Firefox clients cannot properly
browse the site.
> When trying to access the url I get the dialog box
> You have chosen to open
> which is a: application/octet-stream
> from: http://www.....
> What should Firefox do with this file?
> Open with....
> Save to Disk
>
> This only happens on my one web server.
> If I use another 2003 server internally it does not have a problem
> If I use my XP station which is IIS 5, there is no problem.
> So it must be a config issue on my 2003 web server.

RE: IIS 6.0 and Firefox

I have recently been having similar errors. Based your posting as well as my personal experience, I think I have tracked the problem (but no solution as yet).

It seems that it may be the IIS Custom errors that Mozilla cannot interpret correctly. I receive my "You have chosen to open...application/octet-stream" message in Mozilla when requesting pages on my IIS server that respond with a "403-4 HTTPS:\\ required". Other people say that are prompted when requesting a directory rather than a particular file in which case the cause may be a "403-? Directory Browsing not allowed" response.

Under IIS, Web Site, right-click Properties, Custom Errors tab you can see a list of error codes and the IIS error pages they link to. All custom error messages that link to the \Windows\help\iisHelp\Common\error-code.htm files seem to generate the application/octet-stream error message in Mozilla. If these custom error message are set to 'Default', then Mozilla displays them correctly (but they are not as nicely designed as the IIS versions).

Also, try this: When prompted by Mozilla with the application/octet-stream message, save the file as a temporary .htm file and open it again in Mozilla (or choose Open With and navigate to Firefox.exe). The page will them display correctly and I reckon it will look like a IIS error message which would partially confirm my reasoning.

If you have found, or end up finding a solution, I would like to hear it (CoreyPlover@hotmail.com)


From http://www.developmentnow.com/g/59_2005_3_0_0_374128/IIS-6-0 -and-Firefox.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com

Re: IIS 6.0 and Firefox

I do not see application/octet-stream for my IIS custom errors, so you
definitely have some other configuration causing the issue. Custom ISAPI
Filters/Extensions can do this. Also if you have a * MIME Map defined to
application/octet-stream, it can also happen.

Bottom line: this is not an IIS6 "compliance" or "compatibility" issue. You
have some misconfiguration that needs to be fixed

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Corey" wrote in message
news:f7b40b23-45d5-4160-982b-7589840169dc@msnews.microsoft.c om...
I have recently been having similar errors. Based your posting as well as my
personal experience, I think I have tracked the problem (but no solution as
yet).

It seems that it may be the IIS Custom errors that Mozilla cannot interpret
correctly. I receive my "You have chosen to open...application/octet-stream"
message in Mozilla when requesting pages on my IIS server that respond with
a "403-4 HTTPS:\\ required". Other people say that are prompted when
requesting a directory rather than a particular file in which case the cause
may be a "403-? Directory Browsing not allowed" response.

Under IIS, Web Site, right-click Properties, Custom Errors tab you can see a
list of error codes and the IIS error pages they link to. All custom error
messages that link to the \Windows\help\iisHelp\Common\error-code.htm files
seem to generate the application/octet-stream error message in Mozilla. If
these custom error message are set to 'Default', then Mozilla displays them
correctly (but they are not as nicely designed as the IIS versions).

Also, try this: When prompted by Mozilla with the application/octet-stream
message, save the file as a temporary .htm file and open it again in Mozilla
(or choose Open With and navigate to Firefox.exe). The page will them
display correctly and I reckon it will look like a IIS error message which
would partially confirm my reasoning.

If you have found, or end up finding a solution, I would like to hear it
(CoreyPlover@hotmail.com)


From
http://www.developmentnow.com/g/59_2005_3_0_0_374128/IIS-6-0 -and-Firefox.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com

RE: IIS 6.0 and Firefox

I agree with you completely. Now I just need to figure out where that misconfiguration is coming from. I will check the Custom ISAPI Filters/Extensions and the .* MIME type mapping when I am back in the office. This is simply an out of the box IIS 6.0 configuration, with ASP.NET enabled as per Microsoft's Outlook Web Access instructions.

I even used a download manager to request the root directory website and I can see the request that receives the application/octet-stream 403 Forbidden response.

Should I add all the default MIME-types to the Mime Map section (i.e. ,htm -> text.html, etc) or should all the default ones be configured internally?

Thanks for all your help.


From http://www.developmentnow.com/g/59_2005_3_0_0_374128/IIS-6-0 -and-Firefox.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com

RE: IIS 6.0 and Firefox

I must admit David, you are a genius.

The MIME Type of .* application/octet was indeed the problem. Removing it allowed all those IIS custom messages through to Mozilla without any problems.

Also, I think I have discovered that the culprit was Trend Micro's OfficeScan web console (I sure didn't put that .* entry there as I know Microsoft says it could constitute a security risk). My guess is that OfficeScan uses it for one of two reasons:
1. A few of its HTML pages were designed without proper HTML content-types and so may used the * application/octet-stream entry to overcome this; or
2. It uses a few .exe extensions in its URLs to facilitate a login screen and so uses the .* extension to serve these binary streams.

Thank you SO much for all your help David.

From http://www.developmentnow.com/g/59_2005_3_0_0_374128/IIS-6-0 -and-Firefox.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com

Re: IIS 6.0 and Firefox

Glad to hear the issue is resolved.

I am actually pretty shocked that a security product would place a * MIMEMap
on IIS. It pretty much turns off a security feature we placed in IIS6 to
prevent unintended downloads.

Regarding your guesses (purely for addition information/understanding):

Given any URL (and any extension), there's basically only two actions that
IIS will perform:
a. Serve the resource as-is, as a download, to the client machine. This will
use the MIME Type to determine the correct Content-Type header to send on
the response. Client uses the Content-Type to determine what to do with the
downloaded resource.
b. Execute the resource according to some definition of "execution" on the
server to generate some arbitrary response output and send that to the
client machine. For example, in the case of an ASP page, IIS gives the ASP
page to ASP.DLL, an ISAPI, which opens, reads, parses, and executes the
script code inside of the file named by the URL to generate some content,
and it then tells IIS to send that generated content back to the client.
Most of the time, the content is interpreted as HTML, but it can also be
interpreted as a download -- once again, depending on the Content-Type
header (amongst other headers)

Given this info, it should be clear that those URLs with .exe in them must
be of type (b). Type (a) would have resulted in a EXE file downloaded to the
client, and just about all browsers will then ask for your permission to
launch it on your computer. I doubt this is what happened. And URLs of type
(b) do NOT need a MIME Type definition at all -- they just execute as-is, on
the server to, generate some arbitrary response output that is sent to the
client machine and likely interpreted as HTML by the browser and displayed.
No MIME Type involved here.

As for the possibility that the * MIME Type is used to fix broken HTML
pages -- that is unlikely because broken or not, the HTML pages will get
downloaded by the client. The only thing the MIME Type changes is how the
client interprets the content (and therefore affects the action it
performs). Classic HTML has "text/html" Content-Type, which browsers
interpret as first download, then display as HTML -- while
application/octet-stream is often interpreted as just download and then ask
the user, given their local Extension-mapping for the resource extension,
what to do. Frequently, browsers just give you the "download and save"
option. Once again, * MIME Type doesn't fix anything because HTML pages are
usually meant to be downloaded and displayed, which application/octet-stream
does not do.

My theory is that this product is meant to provide software downloads for
other machines in the Office (for example, file signatures using
non-standard extensions like .virsig), and they found that IIS6 prevents the
download of unknown extensions which do not have a MIME Type. However,
instead of just adding MIME Types for their specific non-standard
extensions, they added * to simply make ALL files on your web server
downloadable -- at the cost of your security and other hassles. I mean,
don't you want all files on your web server to be automatically
downloadable? ;-)

For example, if you had accidentally copied a file called user_passwords.ini
onto the web server, IIS6 will actually prevent the static download of such
a sensitive file simply because .ini did not have a MIME Type -- it is
usually not meant to be downloaded. The * MIME Type breaks that security and
allows that file to be downloadable by default. Gee, thanks...

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Corey Plover" wrote in message
news:cabe6304-e5ae-4e9c-9d9a-ee7cc84420d1@msnews.microsoft.c om...
I must admit David, you are a genius.

The MIME Type of .* application/octet was indeed the problem. Removing it
allowed all those IIS custom messages through to Mozilla without any
problems.

Also, I think I have discovered that the culprit was Trend Micro's
OfficeScan web console (I sure didn't put that .* entry there as I know
Microsoft says it could constitute a security risk). My guess is that
OfficeScan uses it for one of two reasons:
1. A few of its HTML pages were designed without proper HTML content-types
and so may used the * application/octet-stream entry to overcome this; or
2. It uses a few .exe extensions in its URLs to facilitate a login screen
and so uses the .* extension to serve these binary streams.

Thank you SO much for all your help David.

From
http://www.developmentnow.com/g/59_2005_3_0_0_374128/IIS-6-0 -and-Firefox.htm

Posted via DevelopmentNow.com Groups
http://www.developmentnow.com