ASP.NET 视，网址路由：最大的路径(URL)的长度

StackOverflow https://stackoverflow.com/questions/1185739

题

的情景

我有一个应用程序，其中我们花了好老query string URL结构：

?x=1&y=2&z=3&a=4&b=5&c=6

和改进的路径结构：

/x/1/y/2/z/3/a/4/b/5/c/6

我们使用ASP.NET 视和(自然地)ASP.NET 路由。

的问题

问题是，我们的参数是动态的，并没有(从理论上)没有数量限制的参数，我们需要适应。

这是所有美好直到我们得到了命中通过以下火车：

HTTP错误400.0-坏的请求 ASP。净检测的无效字在的网址。

IIS会把这个错误的时候我们的网址得过去一定的长度。

的细节问题

这里就是我们发现：

这不是一个IIS问题

IIS不会有一个最大路长度的限制，但上述错误是不是这样。

了解点iis点网 如何使用请求筛选 部分"过滤基于请求限制"

如果路太长for IIS,它会投掷一404.14，不是一个400.0.

此外，IIS max路径(和查询)的长度，是可配置：

<requestLimits


   maxAllowedContentLength="30000000"


   maxUrl="260"


   maxQueryString="25" 


              />

这是一个ASP.NET 的问题

经过一些调查:

IIS论坛 线：ASP.NET 2.0最大URL长？http://forums.iis.net/t/1105360.aspx

事实证明，这是一个ASP.NET (好的,.净真的)问题。

问题的核心是，我可以告诉，ASP.NET 无法处理的路径超过260人物。

钉在棺材里的是，这也证实了菲尔*哈克自己：

堆溢出 ASP.NET url MAX_PATH限制 问题ID 265251

这个问题

那么，有什么问题吗？

问题是，有多大一个限制是这个吗？

我应用程序，这是一个处理凶手。对于大多数应用程序，它可能是一个不是问题的问题。

怎么开?没有哪里哪里ASP.NET 路由是所提到的，我都听过一个窥视有关这种限制。事实上，ASP.NET 视使用ASP.NET 路由选择，使这一影响更大。

你怎么想?

有帮助吗？

解决方案

我最终使用在web.config以下来解决使用MVC2和.NET Framework 4.0此问题

<httpRuntime maxUrlLength="1000" relaxedUrlToFileSystemMapping="true" />

其他提示

要解决这个问题，为此：

在根web.config为项目，对System.Web节点下：

<system.web>
    <httpRuntime maxUrlLength="10999" maxQueryStringLength="2097151" />
...

此外，我不得不在system.webServer节点下添加此或我有一个安全的错误我长的查询字符串：

<system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="10999" maxQueryString="2097151" />
      </requestFiltering>
    </security>
...

Http.sys 服务编码与默认的最大的260个字符的每Url段。

一个"Url段"在这一上下文的内容之间的"/"符的网址。例如：

http://www.example.com/segment-one/segment-two/segment-three

最大允许Url段的长度可以改变登记册的设置：

  • 关键： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
  • 价值： UrlSegmentMaxLength
  • 类型：数
  • 数据：(您想要的新网址段允许的最大的长度，例如4096)

更多关于http.sys 设置：http://support.microsoft.com/kb/820129

所允许的最大值为32766。如果一个较大的数值是指定的，它将会被忽略。(贷：胡安*门德斯)

重新启动电脑是需要作出改变，以此设置生效。(贷：大卫Rettenbacher，胡安*门德斯)

OK所以我张贴的原因，这是也是因为我们已经找到了解决办法的一部分。

我希望这将是有用的人在未来：d

的解决方法

解决方法很简单，这是相当不错的了。

因为我们知道该网站的部分将需要使用动态参数（因此将有一个动态路径和长度），我们能够避免它甚至打ASP之前拦截它发送这个长的URL到ASP.NET路由。 NET

输入IIS7 URL重写（或任何等同的重写模块）。

我们建立了这样的规则：

    <rewrite>
        <rules>
            <rule>
                <rule name="Remove Category Request Parameters From Url">
                <match url="^category/(\d+)/{0,1}(.*)$" />
                <action type="Rewrite" url="category/{R:1}" />
            </rule>
        </rules>
    </rewrite>

基本上，我们正在做的是只是保持足够的路径能够为下游调用正确的路线。我们黑客关闭URL路径的其余部分。

在什么地方URL的休息去了？

那么，当重写规则被触发时，IIS7 URL重写模块自动地设置该头中的请求：

HTTP_X_ORIGINAL_URL

下游，在该解析而不是着眼于路径的动态路径，该应用的一部分：

HttpContext.Request.Url.PathAndQuery

我们看那个头而不是：

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

问题解决了......差不多！

的断枝

访问页眉

在情况下，你需要知道，访问IIS7重写模块标题，您可以通过两种方式做到这一点：

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

或

HttpContext.Request.Headers["X-ORIGINAL-URL"]

修复相对路径

什么也将注意到的是，在上述设置中，所有相对路径打破（带中定义的URL的“〜”）。

这包括与ASP.NET MVC HtmlHelper和UrlHelper方法（如Url.Route("Bla")）中所定义的URL。

这是其中访问ASP.NET MVC代码是真棒。

在System.Web.Mvc.PathHelper.GenerateClientUrlInternal()方法中，存在被以查看是否相同的URL重写模块标头中存在（见上文）进行检查：

// we only want to manipulate the path if URL rewriting is active, else we risk breaking the generated URL
NameValueCollection serverVars = httpContext.Request.ServerVariables;
bool urlRewriterIsEnabled = (serverVars != null && serverVars[_urlRewriterServerVar] != null);
if (!urlRewriterIsEnabled) {
    return contentPath;
}

如果是这样，一些工作做是为了保留原始URL。

在我们的例子，因为我们没有使用URL在“正常”的方式改写，我们要短路这一过程。

我们要假装没有URL重写发生的事情，因为我们不希望相对路径的原始URL的背景下考虑做的。

这是我能想到的最简单的黑客是完全删除该服务器变量，所以ASP.NET MVC不会找到它：

protected void Application_BeginRequest()
{
    string iis7UrlRewriteServerVariable = "HTTP_X_ORIGINAL_URL";

    string headerValue = Request.ServerVariables[iis7UrlRewriteServerVariable];

    if (String.IsNullOrEmpty(headerValue) == false)
    {
        Request.ServerVariables.Remove(iis7UrlRewriteServerVariable);

        Context.Items.Add(iis7UrlRewriteServerVariable, headerValue);
    }
}

（注意，在上述方法中，我除去Request.ServerVariables报头但仍保留它，在Context.Items积攒它。这样做的原因是，我需要在请求管访问标头值稍后。 ）

希望这有助于！

我想你想很难使用GET。尝试改变请求方法POST和把那些查询字符串参数到请求机构。

长URL不利于SEO为好，不是吗？

我在使用ASP.NET网页API 4，其产生稍微不同的错误的类似最大URL长度问题：

404错误

对于我的修复上面通过用以下两个标记更新的Web.config描述：

<system.web>
    <httpRuntime maxUrlLength="10999" maxQueryStringLength="2097151" />

和

<system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="10999" maxQueryString="2097151" />
      </requestFiltering>
    </security>

看来，硬编码的最大的URL长度已经固定在.NET 4.0 。特别地，现在存在与web.config部分：

<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" />

这可以展开允许的URL的范围。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top