다음을 통해 공유

HOWTO: Allow file downloads (including .exe) on IIS 6.0, Part 2

  • 아티클

Some users have reported that IIS6 still refuses to allow an EXE file to download even after removing "Scripts and Executables" Execute Permission and making sure that .EXE has a MIME Type. Alright... I will have to come up with some more non-obvious reasons as possible explanations, as I now detail...

Question:

I have read your blog on how to make exe downloadable in IIS 6.0. I have followed your instructions to the letter and I can get everything to download except the exe files. I have made sure that only scripts are allowed in the execute permissions, I have made sure that a mime exist for .exe application/octet-stream. When I rename the executable from lets say x.exe to x.bin I am able to download the file so I know IIS is finding the file, however it will not download it as an executable. If you know of anywhere else I should be checking I would greatly appreciate it. I know you must be inundated with request.

Thanking you ahead of time

Answer:

Hmm... you are suggesting an interesting mystery that looks like an issue with IIS6, but I am not yet convinced that we have ruled out user misconfiguration. We all know how clever users can be at shooting themselves in the foot. ;-)

So, what you are saying is that:

  1. Only "Scripts" Execute permissions are enabled for the URL.
  2. MIME Type definitely exists for the .EXE extension.
  3. Yet .EXE resource is still not downloading.

Well, according to my previous discussion on how IIS decides to handle a given request, IIS is either executing the code on the server or it is sending it as download to the client. And since you say that it is not downloading to the client, I can only presume that IIS is still executing the EXE file on the server.

You can confirm this by looking up the IIS log file entry for the request, located at %SYSTEMROOT%\System32\LogFiles\W3SVC#\*.log . It probably has either "404 2 1260" or "404 0 2" as the Status, Sub-Status, and Win32 error codes.

Well, if the .EXE is still executing on the server and you only have "Scripts" Execute Permission, then you must have configured an application mapping for the .EXE extension to run some Script Engine, and either that Script Engine does not exist (resulting in "404 0 2"), or it is not allowed in the Web Service Extension ("404 2 1260"). I consider both to be more clever user misconfiguration.

Now, I do not know WHY you have .EXE configured as an application mapping. All you need to do is enable "Scripts and Executables" Execute Permission and the .EXE will execute on the server. In other words, the following two configurations are pretty much the same logically (though they are different in terms of ACL requirements and other NT permissions, but let's ignore that for now, for the sake of conceptual clarity):

  1. Configure .EXE application mapping to be run by CMD.EXE and Execute Permission is "Script".
  2. No application mapping for .EXE and Execute Permission is "Scripts and Executables".

#1 is a misconfiguration that I have seen some users make, but I do not understand why. I would really like to hear some user comments as to why you are configuring #1 to logically accomplish #2.

If you truly want .EXE to be downloadable, then you should just configure Execute Permission to "None". In that case, IIS never bothers trying to execute anything on the server - all requests should download. If that still does not work, then I can only presume that you have some custom ISAPI Filter running on the server performing arbitrary behavior, and I cannot give reasonable advice on arbitrary behavior...

//David

Comments

  • Anonymous
    October 16, 2005
    The comment has been removed

  • Anonymous
    October 16, 2005
    Gabor - Unfortunately, your observation is merely "something is wrong" while we really need to determine whether the issue lies on the client, server, or network to make any progress.

    Remember, the server cares nothing about the MIME Type - it is just a string sent as response headers. By default, .CAB has a MIME Type in the system Registry and in the IIS global MIME Type table, so that is why it is even downloadable.

    So, as far as server-correctness is concerned, IIS just needs to make sure the exact bits of the file was sent over the wire according to HTTP protocol. What the client does on the other end - that is not IIS's concern.

    My recommendation is to use Network Monitor from Add/Remove Programs on Windows Server 2003 to diagnose this.

    If IIS6 sent the right bits, your problem is totally on the client side, and you need to look at the actual response headers of the Network Monitor capture for clues on how the client interprets the download.

    If IIS6 sent the wrong bits, then we can look further at IIS6 configuration.

    //David

  • Anonymous
    October 17, 2005
    David, one question - do you agree IIS should or should not return my beloved cab file when on the given website, a mime type ".cab" is manually set to "application/octet-stream"? Without defining a mime for the file, I think we both agree that IIS returns a 404 since it's not in its list of allowed extensions. So - should application/octet-stream work for this file type? Because it did not.

  • Anonymous
    October 17, 2005
    Gabor - The issue of "it did not work" is tangential to your question. Let me explain.

    IIS6 will return the CAB file when you have a specific MIMEType for that extension. Just be aware that global MIMEType changes require restarting IIS to take effect while per-URL MIMEType changes take effect immediately.

    On a default IIS6 installation, CAB files should download with no additional configuration. This is because both the Registry and the global MIMEMap provide definitions for the MIMEType.

    I went and tested it out and it worked as expected. I just did 'DIR > test.cab', made a request for /test.cab, and I saw that it downloaded just fine with the correct Content-Type header. No idea where you are seeing 404 from.

    As to whether "application/octet-stream" works for this file type, that depends on the client. As I said earlier, the only thing IIS is responsible for is to send the bits of the resource faithfully, and also to decorate the response Header with the Content-Type header representing the MIMEType. What the client does with the information at that point, it is totally up to the client.

    I realize that from your perspective it is simply "not working" so you want a solution, but please realize from my perspective I am not seeing anything wrong from IIS6 at all.

    Maybe you are having problems with IE's automatic content-sniffing algorithm and the resource extension.

    I can just say that without using Network Monitor to examine your problematic request / responses, we are simply going to go around in circles and not make progress.

    //David

  • Anonymous
    October 17, 2005
    You know David I have seen this behavior of the executing exe even though only scripts are allowed to run before. I can't remember exactly where but there is another setting somewhere in the Front Page Server Extensions which can cause this as well I thought it was quite odd because it would trump the actual IIS settings. This could have also been on an older version of Server Extensions I seen but I distinctly remember it because it caused me so much grief. Sorry I can not remember where exactly this was because I chased this around for a long time and a couple years ago. Turning it off turning it on in IIS trying to figure out why the exe was still executing. I remember though it had to do with the FP Extensions though.

  • Anonymous
    October 17, 2005
    Jeff - Thanks for the additional possibilities.

    The key thing to remember is that ISAPI Filters and Extensions CAN alter "normally expected" IIS behavior, and that is by-design. ISAPI need to be able to do this to extend server functionality.

    This is why I always say that if the behavior of the web server does not make logical sense according to IIS rules, then there is probably an ISAPI involved somewhere... at which point all bets are off since it can implement arbitrary behavior.

    //David

  • Anonymous
    December 06, 2005
    The comment has been removed

  • Anonymous
    December 06, 2005
    The comment has been removed

  • Anonymous
    February 13, 2006
    The comment has been removed

  • Anonymous
    February 19, 2006
    I have found (on IIS 5 at least) that the IIS lockdown tool will prevent .exe files being downloaded.

  • Anonymous
    February 20, 2006
    Indeed Tim is right:

    - IIS lockdown tool  prevents .exe files being downloaded.

    For example on my computer, the:

    %WinFolder%system32inetsrvurlscanurlscan.022106.log file says:

    -URLs must contain only ANSI characters.
    -URLs must not contain any dot except for the file extension.
    - Requests for following extensions will be rejected:
    '.exe'
    '.bat'
    '.cmd'
    '.com'
    '.htw'
    '.ida'
    '.idq'
    '.htr'
    '.idc'
    '.shtm'
    '.shtml'
    '.stm'
    '.printer'
    '.ini'
                   .log'
    '.pol'
    '.dat'

    Alexandru Matei

  • Anonymous
    March 08, 2006
    Thanks, your idea worked great.  Saved me a lot of time and trouble.   Kudos.

  • Anonymous
    April 07, 2006
    i disabled 'enable content expiration' and it fixed my exe download problem.

  • Anonymous
    April 08, 2006
    joey - If you look in the IIS log file you will see that a 200 OK is recorded for that request. So, IIS actually served the file download successfully (and from my perspective, allowed the file download). What the client does with the download is arbitrary.

    In this case, this is due to a known behavior of IE. IE has various settings that cause it to not accept a download - for example, if you set:
    - Cache-Control: no-cache (like via Content-Expiration or dynamic code that generates)
    - Compression enabled with Cache-Control: no-cache
    - SSL download with IE's "Don't save encrypted pages to disk" checked

    In these cases, IIS actually sends the content over the wire as requested and the browser received the content, but the browser REFUSES to let the user get the content as a download.

    //David

  • Anonymous
    April 12, 2006
    I have make step-by-step all the operations as described in your post. But my  IIS still does not carry out the .exe file.
    In my IIS log I have

    #Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
    2006-04-11 10:21:27 W3SVC1 127.0.0.1 GET /barid/algocgi/style1.css - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 200 0 0
    2006-04-11 10:21:27 W3SVC1 127.0.0.1 GET /test/test/test.exe - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 200 0 0
    2006-04-11 10:21:27 W3SVC1 127.0.0.1 GET /test/test/test/01.gif - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 200 0 0
    2006-04-11 10:21:27 W3SVC1 127.0.0.1 GET /test/test/test/BD11.gif - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 200 0 0
    2006-04-11 10:21:27 W3SVC1 127.0.0.1 GET /test/test/test/BF11.gif - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 200 0 0

    and afer a few minutes i have this log in IIS log file.

    #Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
    2006-04-13 10:02:54 W3SVC1 127.0.0.1 GET /test/test/test.exe - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 502 1 233
    2006-04-13 10:07:34 W3SVC1 127.0.0.1 OPTIONS /test/test/test.exe - 80 - 127.0.0.1 - 502 1 233

    and in my broswer i have this error message

    CGI Timeout
    The specified CGI application exceeded the allowed time for processing. The server has deleted the process.

    Im sorry for my orthography, but im verry bad in anglish.
    Thanks.

  • Anonymous
    April 12, 2006
    The comment has been removed

  • Anonymous
    April 12, 2006
    The comment has been removed

  • Anonymous
    April 12, 2006
    The comment has been removed

  • Anonymous
    April 14, 2006
    The comment has been removed

  • Anonymous
    April 14, 2006
    The comment has been removed

  • Anonymous
    April 15, 2006
    I have make oder tests
    I added a one application extention mapping for test.exe in my IIS server and i allow all verbs, in this case my application turn correctely and when i run nph-test.exe in my browser a have Content-Type: text/html in top of my page and and right after the authentification part.
    But if I puts my username and password the application blocks again.
    In IIS 5.0 that functions correctly I dont have any problem.

  • Anonymous
    April 15, 2006
    The comment has been removed

  • Anonymous
    April 25, 2006
    Possibly your .exe's can get blocked by URLScan

    Then your log would contain <Rejected-By-UrlScan>
    E.g.
    2006-04-26 01:32:39 10.254.48.61 - 10.108.117.202 80 GET /<Rejected-By-UrlScan> ~/dir/application.exe 404

    In such a case have URLScan.ini configured to allow *.exe or whatever it is by following this article.
    http://support.microsoft.com/kb/326444/

    URLScan.ini location - %WINDIR%System32InetsrvURLscan
    Log files location -

  • Anonymous
    February 17, 2009
    I was having similar issue and needed to adjust the URLscan.ini as Nausher suggested.

  • Anonymous
    July 15, 2011

  1. Change the Website or application Virtual Directory permission to "Scripts Only" (Whichever is applicable).
  2. Restart IIS
  3. Download .exe's & Enjoy  !!
  • Anonymous
    June 24, 2014
    i'm  configure IIS 7 to allow downloading .exe files  -->> Handler Mappings -> Add Module Mapping   Request path: *.exe   Module : CgiModule   Name : Test Request Restrictions..   Mapping : File   Verbs : All verbs   Access : None but can not download exe file