Re: Cant't download "exe" file because of IIS version

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Peter McLaren (PeterMcLaren_at_discussions.microsoft.com)
Date: 10/13/04 

Date: Wed, 13 Oct 2004 09:00:41 -0700

Your advice has been extremely helpful!

I defined the MIME type for the specific EXE to be application/octet-stream,
stopped and started the Web Service and tried to download the application and
got the MIME type as application/octet-stream! Unfortunately, I still wasn't
given the opportunity to save the application, but it appears as though this
is an IE problem, not an IIS6 problem.

Just to test that theory, I installed Firefox and was able to save the
application without any difficulty.

Now all I have to do is figure out what setting I have to change in IE 6
that will prompt me to save the executable from our local intranet site.

"David Wang [Msft]" wrote:

> To be certain:
>
> There are two generic ways that the Content-Type header (this is what the
> MIME Type controls) can be sent on a response:
> 1. By IIS via the static file handler
> 2. By non-IIS code via the dynamic handlers
>
> If IIS sent it via the static file handler, the Content-Type would be
> determined by a merge of MIME Type for a given extension from the following
> locations:
> 1. Registry
> 2. IIS Global MIME Type
> 3. Nearest inherited MIME Type for the URL
>
> If the content was sent/modified by other dynamic handlers, the
> configuration is arbitrary. ISAPI Filters and ISAPI Extensions "filtering"
> the request can both affect the Content-Type in arbitrary manners.
>
>
> Here's a pragmatic way to figure out what is going on:
>
> In the IIS Manager UI, select the exact EXE file itself, right-click
> properties, select "Http Headers", and set the MIME Type for the EXE
> extension right on the file itself. Close the UI to ensure the settings are
> saved, then NET STOP W3SVC & NET START W3SVC on the commandline, and
> finally, make a request to that EXE file and see what Content-Type is
> returned.
>
> If this response contains the MIME Type you set, then you're seeing the IIS
> static file handler working to send the download (and the rest of my earlier
> instructions should apply). If the response does not contain the MIME Type
> you set, then we've got some other dynamic handler breaking things by
> handling the download incorrectly -- and you'll need to debug further to
> figure out what is doing this and get that component fixed.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
> "Peter McLaren" <PeterMcLaren@discussions.microsoft.com> wrote in message
> news:A9916518-D8BB-402E-BFD2-F9B3E8FF47B5@microsoft.com...
> Thank you again for the information!
>
> First, I stopped the services as you suggested (below) and restarted them. I
> got the same result as before (Executbale downloaded, but I was not given an
> opportunity to save the file).
>
> So I copied the executable to another web server and tried it (using the
> same browser machine). It worked beautifully.
>
> I performed a hunt in the registry in both the problematic server and the
> server which functioned and found in HCR\.exe, the (apparent) MIME type as
> application/x-msdownload on both machines. Just for fun, I changed the
> (apparent) MIME type in the problematic server to application/octect-stream
> (after backing up the registry key first). Performed the stop and start of
> services below and tried a download again. Same result. Tried an IISReset
> and
> still got the same result. Then I restored the registry key, and performed
> an
> IISreset. Same result
>
> The only conclusion that I can reach is that there is some application/ISAPI
> filter on the problematic server that has caused this problem to appear. The
> only problem is that this problematic server is a functioning production
> server for all the other applications that run on it, except for this new
> application that requires the download of an executable. Yes, there are ways
> to get around the download of the executable from the problematic server,
> but
> that is not the right answer. The right answer, as far as I am concerned, is
> that the download should work along with everything else.
>
> It looks like I am going to be very busy trying to determine which
> application is causing the problem.
>
> Anyway, thanks for your help!
>
> "David Wang [Msft]" wrote:
>
> > Changing MIME Type at the global (Websites) level requires restarting IIS
> to
> > take effect. If it was per-website then it would have taken effect
> > immediately.
> >
> > The default MIME Type in IIS for .exe is application/octet-stream .
> >
> > Since it is a static file download, it is possible that you are seeing a
> > response from the kernel mode cache of your earlier requests. I
> recommend:
> > NET STOP HTTP /Y & NET START W3SVC
> >
> > to clear everything out and start again. I also recommend using different
> > machines for the server/browser.
> >
> >
> > --
> > //David
> > IIS
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > //
> > "Peter McLaren" <PeterMcLaren@discussions.microsoft.com> wrote in message
> > news:CC27AB2D-64C8-4680-99A9-C56E51958EEE@microsoft.com...
> > OK.
> >
> > First, thanks for the reply!
> > I have Ethereal installed so I used it instead of NetMon.
> >
> > I removed the MIME type for EXE. Did not perform an IISReset.Started
> > Ethereal. Clicked the link and still got the same error message.
> >
> > The file was downloaded (I can see HTTP Continuation packets). When I
> looked
> > at the download type it was still set to the MIME type that I just removed
> > (application/x-msdownload).
> >
> > Went back to IIS Manager and started at the top of the Web Site Hierarchy
> > looking for a MIME definition for EXE. There was none at the server level,
> > none at the Default Web Site Level, none at the Virtual directory level.
> >
> > Performed an IISReset. Started Ethereal. Clicked the executable link and
> got
> > the same error message. Looked in the capture file and the file was
> > downloaded again, but the MIME type was still set to
> > application/x-msdownload.
> >
> > OK. I'll bite. Where is this MIME definition coming from if it is not
> > defined in IIS Manager? Do I have to perform a hard reboot?
> >
> >
> >
> > "David Wang [Msft]" wrote:
> >
> > > Hmm... on a default IIS6 install with no further configuration, .PDF and
> > > ..EXE are automatically downloadable by any browser. I suggest you:
> > > 1. Get rid of your MIME Type for .EXE. The correct one for EXE is
> already
> > > defined
> > > 2. Use Netmon to sniff the network between client/server and see if IIS
> > sent
> > > the file to the browser or not.
> > >
> > > If #2 shows that the EXE file is sent to the browser, start looking at
> IE.
> > > If #2 shows that the EXE file is not sent to the browser, we can
> > investigate
> > > further. Since this scenario works for me from a default install, I
> > suspect
> > > you might have other software preventing proper server operation.
> > >
> > > IE does have some code to detect download type, extension, and
> > content-type,
> > > so you could be confusing it somehow.
> > >
> > > --
> > > //David
> > > IIS
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > //
> > > "Peter McLaren" <PeterMcLaren@discussions.microsoft.com> wrote in
> message
> > > news:1F4DDD53-BF93-4178-BC34-4B002DACC6C9@microsoft.com...
> > > I have a somewhat similar problem to Claude.
> > >
> > > I have Execute Permissions on the virtual directory set to "Script
> Only".
> > I
> > > have set a MIME type for EXE to application/x-msdownload. I click on the
> > > link
> > > to download the exe and it times out and I get a dialog box indicating:
> > > "Internet Explorer cannot download x.exe from website. Internet Explorer
> > was
> > > not able to open this internet site. The requested site is either
> > > unavailable
> > > or cannot be found. Please try again later."
> > >
> > > The NTFS File permissions on this x.exe file is set to Everyone/change.
> > > There is a PDF file in the same directory that can be viewed perfectly.
> > >
> > > Does anybody have any ideas as to what else I might need to do to get
> this
> > > exe to download in IIS6?
> > >
> > > Thanks
> > >
> > >
> > > "David Wang [Msft]" wrote:
> > >
> > > > Given this request:
> > > > http://myserver/download/program.exe
> > > >
> > > > Should IIS execute program.exe on the server, as a CGI, to generate a
> > > > response, or should IIS send the contents of program.exe to the
> browser
> > as
> > > a
> > > > download? There is no way for anyone to figure out the behavior you
> > > > actually want, so IIS gives you a configuration choice to determine
> > it --
> > > > Execute Permissions.
> > > >
> > > > If it is set to "Scripts and Executables", then IIS treats the URL as
> > > > "execute program.exe on the server". Otherwise, it treats it as "send
> > the
> > > > contents of program.exe to the browser as a download".
> > > >
> > > > Finally, on IIS6, there are two other security measures associated
> with
> > > > "executing code on the server" and "sending contents to the browser as
> > > > download". IIS6 does not allow any code to execute on the server
> unless
> > > it
> > > > is allowed on the Web Service Extensions list, and IIS logs a 404.2
> for
> > > any
> > > > violation of this security setting. IIS6 does not allow any static
> > > content
> > > > to be downloaded from the server unless it has a registered MIME Type
> > > > setting for the given extension, and IIS logs a 404.3 for any
> violation
> > of
> > > > this security setting.
> > > >
> > > > --
> > > > //David
> > > > IIS
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > > rights.
> > > > //
> > > > "Ouatzefeuq'" <nomail@nospam.fr> wrote in message
> > > > news:Xns955ED0B044DE3nomailnospamfr@193.252.19.141...
> > > > "doug" <anonymous@discussions.microsoft.com> wrote in
> news:096101c495ab
> > > > $41dc9d60$a401280a@phx.gbl:
> > > >
> > > > > Ok...what does happen? Make sure you don't have the
> > > > > virtual directory setup to run scripts and executables.
> > > > >
> > > > > doug
> > > >
> > > > That's right !? I set it to "Scripts" only and it works...
> > > >
> > > > I don't understand why ? Do you know what it means ? What's the
> relation
> > > > with this option and my problem ?
> > > >
> > > > Thanks anyway :-) !!!
> > > >
> > > > Claude.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>

Relevant Pages

  • Re: IIS 6.0 on Windows Server 2003
    ... These are the general access patterns for a resource (like an EXE): ... Allow the user to browse to a web page, which executes zipcode.exe on the ... Service Extension for zipcode.exe since IIS is executing it directly. ... resources of particular extension that did not have a MIME Type. ...
    (microsoft.public.inetserver.misc)
  • Re: Cantt download "exe" file because of IIS version
    ... The default MIME Type in IIS for .exe is application/octet-stream. ... When I looked at the download type it was still set to the MIME type that I just removed. ...
    (microsoft.public.inetserver.iis)
  • Re: serving .exe files in IIS 6.0
    ... there is a 404 with suberror 3 that indicates that IIS tried to download the ... then adding .exe as a MIME type would have corrected it. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Cantt download "exe" file because of IIS version
    ... MIME Type controls) can be sent on a response: ... If IIS sent it via the static file handler, ... static file handler working to send the download (and the rest of my earlier ... I performed a hunt in the registry in both the problematic server and the ...
    (microsoft.public.inetserver.iis)
  • Re: IE will not open or DL Office ".doc" files, but will ".rtf" fi
    ... > From what I can tell, the status bar displays only the "label" of the link ... But getting back to the task at hand, trying to download a file, ... Document (for extension .doc) has another Action in its list: ... you may be able to detect the MIME type they were downloaded ...
    (microsoft.public.windows.inetexplorer.ie6.browser)