Serving .config files

We have a legacy (classic asp) CRM that I maintain in my organization. Users may upload files through the web front, they are stored on a network share and the filename, uploader, etc is sav开发者_开发百科ed to a database. Everything is well and good with the exception of .config files.

For some reason certain people can download these just fine, but other people recieve this error: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.config' may be incorrect.

it would seem that on some users computers the link for the file is "file://networkshare/filename" (which works) and on other machines it is "http://networkshare/filename". (which doesn't work)

I have the mime type for .config set to text/plain in iss6. All users are running IE8.

The code on the page creates a href links based on records returned from the database.

Why then is there there the difference in the way the link is rendered differently in the same browser on different pc's? How do I allow .config files allowing people to view the sites web.config?

The code that builds the link is:

function getlink(file_nm,path)
{   
    thisPage.navigate.CheckDocumentAttachedToRequest(file_nm, path)
    var sDocLink = path.replace(/\//g,"\\") + "\\" + file_nm;
    return "<A class=\"parislink2\" TARGET=\"_BLANK\" HREF=\"\\\\" + thisPage.get_sServerName() + "\\" + sDocLink + "\">" + file_nm + "</A>";
}

Weird.

I know that IIS 6 will return error 404.3 if a client request refers to a file name extension that is not defined in the MIME types.

However you do have it defined. You can try as a test using the wildcard () in your mime types. ( for the file extension and text/plain for the mime type.) The wildcard can be a security risk but if you are serving up configs..perhaps this application and server are internal to your network and it would be ok to use the wildcard.

I would also check your ISAPI extensions (not filters, but extensions) and make sure .config is still in there. It should be by default.

Defining a mime type at the global level in IIS should filter down through and override any mime types set at the folder level.

An IIS reset is needed everytime you change mime types.

Perhaps it is a browser issue? (an issue on the client side for the links that do not work..an issue like "browser control".)

It is almost as if some of the browsers are interpreting your function correctly when the link is built..and others are substituting "http" instead of "file" as the protocol when they render the HTML from the function call. Perhaps you could hardcode your function to us "file:" as a string that is placed at the begining of your link code. (trying to overide any "http" string that gets place in there by the HTML sent back by the server or rendered by IE8.)

The wildcard was filtered out for security purposes in the above post. (wildcard = "an asterisk")