IIS7 blocks viewing access to files in bin and other asp.net folders

I was just asked to help someone troubleshoot a site that worked fine on Windows Server 2003 / IIS6 but didn't work on Windows Server 2008 / IIS7.  A file was in a folder under the bin folder on the site and displayed an error when trying to view the page.  The path looked something like this:

http://www.sitename.com/subfolder/bin/debug/file.xml

The subfolder wasn't marked as an application, although that doesn't really matter.  The point is that since /bin/ was in the path somewhere, IIS7 wouldn't allow the file.xml to be displayed.  It served up a 404.2 error saying file or directory not found.

404 - File or directory not found.

The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.

Since I knew that it worked in IIS6, I knew that it wasn't asp.net that was blocking it, so I looked in applicationHost.config and found the following under the <requestFiltering> section:

                <hiddenSegments applyToWebDAV="true">
                    <add segment="web.config" />
                    <add segment="bin" />
                    <add segment="App_code" />
                    <add segment="App_GlobalResources" />
                    <add segment="App_LocalResources" />
                    <add segment="App_WebReferences" />
                    <add segment="App_Data" />
                    <add segment="App_Browsers" />
                </hiddenSegments>

So, IIS7 now blocks those key folders and doesn't allow them to be seen.  To the outside world, any page in any of these folders appears to not exist.

There may be times when you really do want to display the page, as in this particular case.  Not to worry, it can be changed easily enough.  This setting in on purpose though, so you usually shouldn't remove it for the whole site.

You can use AppCmd or do it manually from applicationHost.config or web.config.  Since requestFiltering is allowed to be set at the site or folder level by default, it's probably best to set a web.config file in the folder that you want to allow.

To do this, create a web.config file in your folder and type or paste the following into it.  I should look something like this:

<?xml version="1.0"?>
<configuration>
   <system.webServer>
       <security>
          <requestFiltering>
               <hiddenSegments>
                   <remove segment="bin" />
               </hiddenSegments>
           </requestFiltering>
       </security>
   </system.webServer>
</configuration>

If you want to make the change to your applicationHost.config file instead, you can do it by adding a location tag to the bottom of the file (well, almost the bottom - along with the other location tags) like this:

    <location path="sitename.com/subfolder/bin/debug">
        <system.webServer>
            <security>
               <requestFiltering>
                    <hiddenSegments>
                        <remove segment="bin" />
                    </hiddenSegments>
                </requestFiltering>
            </security>
        </system.webServer>
    </location>

You can do this using AppCmd instead.  Just drop to the command prompt and type the following: (Be sure to change the paths to the correct page before running this.)

C:\Windows\System32\inetsrv\appcmd.exe set config "sitename.com/subfolder/bin/debug" -section:system.webServer/security/requestFiltering /-hiddenSegments.[segment='bin']

After making this change, you will be able to view pages normally, even if they have /bin in the site path. 

2 Comments

  • Interesting, thanks for posting this.

    Aside from providing a heads-up on a potential future issue, it demonstrates how easy and friendly IIS 7 is to configure. The same type of configuration issue under IIS 6 would require a machine.config or registry change (i.e., access and control of the server).

    IIS 7 impresses me more and more, and I can't wait to convert my own apps to it.

  • Hi Joseph,

    It sounds like it may have to do with the bindings in IIS. I would start by first pinging the internal URL that you're using and make sure that it resolves to an IP on the server. Then make sure that you have the appropriate binding set in IIS (see week 5: http://dotnetslackers.com/projects/LearnIIS7/).

    If that doesn't work, can you explain what error messages you get?

Comments have been disabled for this content.