Question

我有一个遗产（经典的asp）CRM，我在我的组织中维护。用户可以通过Web前端上传文件，它们存储在网络共享中，文件名，上传器等保存到数据库中。除了.config文件外，一切都很好。

出于某种原因某些人可以下载这些就好了，但是其他人也收到了这个错误： 您请求的页面类型未被提供，因为它已被明确禁止。扩展名“.config”可能不正确。

在某些用户计算机上，文件的链接似乎是“file：// networkshare / filename”（可以正常工作），而在其他计算机上则是“http：// networkshare / filename”。（这不起作用）

我在.6中将.config的mime类型设置为text / plain。所有用户都在运行IE8。

页面上的代码根据从数据库返回的记录创建一个href链接。

为什么那里的链接在不同PC上的同一浏览器中的呈现方式有所不同？如何允许.config文件允许人们查看网站web.config？

构建链接的代码是：

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>";
}

Answer 1

怪异。

我知道如果客户端请求引用未在MIME类型中定义的文件扩展名，IIS 6将返回错误404.3。

但是你确实定了它。您可以在mime类型中使用通配符（）尝试作为测试。（用于文件扩展名，text / plain用于mime类型。）通配符可能存在安全风险，但如果您正在提供配置。也许此应用程序和服务器是您的网络内部的，它可以使用通配符。

我还会检查你的ISAPI扩展（不是过滤器，而是扩展），并确保.config 仍然在那里。它应该是默认的。

在IIS中的全局级别定义mime类型应该过滤并覆盖在文件夹级别设置的任何mime类型。

每次更改mime类型时都需要重置IIS。

也许是浏览器问题？（客户端的一个问题是链接不起作用。像“浏览器控制”这样的问题。）

当构建链接时，几乎就像某些浏览器正确地解释了你的功能......而其他浏览器在从函数调用中呈现HTML时，用“http”代替“file”作为协议。也许你可以将你的函数硬编码给我们“file：”作为一个字符串放在你的链接代码的开头。（试图覆盖由服务器发回或由IE8呈现的HTML所在的任何“http”字符串。）

出于安全目的，在上面的帖子中过滤掉了通配符。（wildcard =“an asterisk”）

提供.config文件

1 个答案: