53

我正在使用 ASP .NET MVC Beta，当我使用这个结尾有一个“点”的 url 时，我得到了 HTTP 404（找不到资源）错误：

http://localhost:81/Title/Edit/Code1。

如果我删除最后的点或点在中间的某个地方，我不会收到错误消息。

我试图调试，但我在 MvcHandler 中的 ProcessRequest 之前从“System.Web.CachedPathData.GetConfigPathData(String configPath)”得到错误。

网址末尾不允许“点”吗？或者有没有办法修复路由定义来处理这个url？

例如：我有一个名为 Detail1 [Id(integer), Code(string), Description(string)] 的表，它通过它的 Id 列与 Master1 具有 FK 关系。每当我选择 Master1 的记录时，我也会选择它的 Detail1 记录来获取它的 Code 字段。为了不每次都进行此连接（因为通常不仅有一个细节，还有多个），我选择不使用 Id 列并制作 Detail1 的代码 PK。

但是当我摆脱 Id 并使用 Code as PK 时，我的路线也开始使用 Code 字段，例如：Detail1\Edit\Code1

此代码可以包含任何内容或结尾，包括 DOT。在某些情况下，我可以在最后禁止 DOT，但有时它真的很有意义。

而且我也看过这篇文章，路线可以非常灵活，所以我不认为我的很奇怪。

所以这就是为什么我做一些如此不标准的事情。有什么建议么？

还有为什么在 url 的末尾有一个 DOT 很奇怪？

4

6 回答 6

54

如果您使用的是 .NET 4.0，则可以在 web.config 的 system.web 部分设置此标志，并且允许：

<httpRuntime relaxedUrlToFileSystemMapping="true" />

我已经对其进行了测试，并且可以正常工作。哈克对此进行了解释。

于 2010-08-22T17:37:04.377 回答
17

在 1.0 及更高版本的每个 ASP.NET 版本中，这可以通过多种方式解决。我知道这是创建此线程后的两年，但无论如何，它是这样的：

原因

创建自定义错误处理程序或在 IIS 中配置自定义页面以重定向 404 将不起作用。原因是 ASP.NET 认为这个 URL 很危险。在内部System.Web.Util.FileUtil，ASP.NET 调用私有方法IsSuspiciousPhysicalPath，该方法尝试将路径映射到（虚拟但合法）文件名。

当生成的合法路径不等于原始路径时，处理停止并且 ASP.NET 代码返回 404（它不向 IIS 或 web.config 询问自定义 404，它自己返回一个，这使得它如此很难对此做些什么）。

Windows 资源管理器的工作方式相同。尝试创建一个以一个或多个点结尾的文件名，即test.txt.. 您会发现生成的名称是text.txt.

ASP.NET中以点结束URL的解决方案

解决方案很简单（一旦你知道，它总是如此）。就在它发出这个 404 之前，它会调用Application_PreSendRequestHeaders一个简单的事件，您可以在其中注册Global.asax.cs（或 VB 等价物）。以下代码将向浏览器返回一个简单的文本，但重定向或任何其他有效响应也是可能的。

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{

    HttpResponse response = this.Context.Response;
    HttpRequest request = this.Context.Request;
    if (request.RawUrl.EndsWith("."))
    {
        response.ClearContent();
        response.StatusCode = 200;
        response.StatusDescription = "OK";
        response.SuppressContent = false;
        response.ContentType = "text/plain";
        response.Write("You have dot at the end of the url, this is allowed, but not by ASP.NET, but I caught you!");
        response.End();
    }
}

注意：当“aspx”不是URL 的一部分时，此代码也有效。即http://example.com/app/somepath。将调用该事件。另请注意，某些路径仍然不起作用（例如，以多个点、井号标签或 < 符号结尾，会导致 400- 错误请求）。再说一次，它确实适用于以引号、空格+斜线或由空格分隔的多个点结尾。

于 2011-03-11T12:34:04.947 回答
6

好吧，在 .NET 4.5 中，我通过在 url 末尾添加“/”解决了这个问题。

因此，在您的情况下，它将是“http://localhost:81/Title/Edit/Code1./”。这是我唯一做的事情，我不必添加 httpRuntime 设置。

于 2012-11-15T12:18:27.793 回答
2

将此添加到处理程序

  <add name="ExtensionlessUrlHandler-Integrated-4.0-ForApi"
 path="api/*"
 verb="*"
 type="System.Web.Handlers.TransferRequestHandler"
 preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
于 2016-12-15T13:19:43.907 回答
-1

也许http://localhost:81/Title/Edit/Code1%2E会奏效。

我用十六进制 ascii 代码逃脱了这个时期。

于 2009-01-10T15:48:46.007 回答
-3

为什么不能有一个以点结尾的 URI？

因为 URI 是一个资源请求，并且在所有相关操作系统上都存在一个历史命令，点字符是扩展分隔符。最后一个点被视为表示文件扩展名，因此点终止没有意义。

还值得一读：

于 2009-01-10T17:04:14.920 回答