70

シナリオ

古き良きクエリ文字列の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 MVCと(当然のことながら)ASP.NETルーティングを使用しています。

問題

問題は、パラメーターが動的であり、(理論的には)対応する必要のあるパラメーターの量に制限がないことです。

次の電車にぶつかるまでは、これで問題ありません。

HTTPエラー400.0-不正な要求ASP.NETがURLで無効な文字を検出しました。

URLが特定の長さを超えると、IISはこのエラーをスローします。

ニッティグリッティ

これが私たちが見つけたものです:

これはIISの問題ではありません

IISには最大パス長の制限がありますが、上記のエラーはこれではありません。

dot iisdotnetの学習リクエストフィルタリングの使用方法セクション「リクエスト制限に基づくフィルター」

パスがIISに対して長すぎる場合、400.0ではなく404.14がスローされます。

さらに、IISの最大パス(およびクエリ)の長さは構成可能です。

<requestLimits


   maxAllowedContentLength="30000000"


   maxUrl="260"


   maxQueryString="25" 


              />

これはASP.NETの問題です

少し突っついた後:

IISフォーラムスレッド:ASP.NET 2.0の最大URL長? http://forums.iis.net/t/1105360.aspx

これはASP.NET(まあ、実際には.NET)の問題であることがわかりました。

問題の核心は、私が知る限り、ASP.NETは260文字を超えるパスを処理できないということです。

これがフィル・ザ・ハック自身によって確認されたという点での棺桶の釘:

Stack Overflow ASP.NETurlMAX_PATH制限質問ID265251

質問

それで、質問は何ですか?

問題は、これはどれくらいの制限があるのか​​ということです。

私のアプリにとって、それは取引キラーです。ほとんどのアプリでは、おそらく問題ではありません。

開示はどうですか?ASP.NETルーティングが言及されている場所では、この制限についてのぞき見を聞いたことがありません。ASP.NET MVCがASP.NETルーティングを使用しているという事実は、これの影響をさらに大きくします。

どう思いますか?

4

7 に答える 7

46

Mvc2と.NetFramework4.0を使用してこの問題を解決するために、web.configで次のものを使用することになりました。

<httpRuntime maxUrlLength="1000" relaxedUrlToFileSystemMapping="true" />
于 2011-04-07T18:23:49.327 に答える
33

これを解決するには、次のようにします。

プロジェクトのルート web.config で、system.web ノードの下に:

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

さらに、これを system.webServer ノードの下に追加する必要がありました。そうしないと、長いクエリ文字列に対してセキュリティ エラーが発生しました。

<system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="10999" maxQueryString="2097151" />
      </requestFiltering>
    </security>
...
于 2013-09-19T21:45:45.913 に答える
33

Http.sys サービスは、既定で Url セグメントあたり最大 260 文字でコード化されています。

このコンテキストでの「Url セグメント」は、Url の「/」文字の間のコンテンツです。例えば:

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

許可される URL セグメントの最大長は、レジストリ設定で変更できます。

  • 鍵:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
  • 価値:UrlSegmentMaxLength
  • タイプ: REG_DWORD
  • データ: (希望する新しい URL セグメントの最大許容長、例: 4096)

http.sys 設定の詳細: http://support.microsoft.com/kb/820129

最大許容値は 32766 です。これより大きな値を指定すると、無視されます。(クレジット: フアン・メンデス)

この設定の変更を有効にするには、PC を再起動する必要があります。(クレジット: David Rettenbacher、Juan Mendes)

于 2011-10-19T07:12:20.320 に答える
17

私がこれを投稿した理由の一部は、回避策を見つけたからでもあります。

これが将来誰かに役立つことを願っています:D

回避策

回避策は非常に簡単で、非常に優れています。

サイトのどの部分で動的パラメーターを使用する必要があるか (したがって、動的なパスと長さが必要になるか) がわかっているため、ASP.NET に到達する前にインターセプトすることで、この長い URL を ASP.NET ルーティングに送信することを回避できます。

IIS7 Url Rewriting (または同等の書き換えモジュール) を入力します。

次のようなルールを設定します。

    <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 Rewrite Module ヘッダーにアクセスするには、次の 2 つの方法があります。

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

また

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

相対パスの修正

また、上記の設定では、すべての相対パス (「~」で定義された URL) が壊れていることに気付くでしょう。

これには、ASP.NET MVCHtmlHelperUrlHelperメソッド ( など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ください。この理由は、後で要求パイプでヘッダー値にアクセスする必要があるためです。)

お役に立てれば!

于 2009-07-26T22:54:09.650 に答える
4

ASP.NET Web API 4 を使用して、同様の最大 URL 長の問題が発生し、わずかに異なるエラーが生成されました。

404 エラー

私にとっての修正は、次のタグの両方で Web.config を更新することによって上記で説明されました。

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

<system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="10999" maxQueryString="2097151" />
      </requestFiltering>
    </security>
于 2018-08-09T18:28:28.510 に答える
2

GETを一生懸命使っていると思います。リクエストメソッドをPOSTに変更して、それらのクエリ文字列パラメータをリクエスト本文に入れてみてください。

長いURLはSEOにも役立ちませんね。

于 2009-07-26T22:36:59.157 に答える
1

ハードコードされた URL の最大長が.NET 4.0 で修正されたようです。特に、次のweb.configセクションがあります。

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

これにより、許可される URL の範囲を拡張できます。

于 2011-04-05T09:23:15.690 に答える