Aby to rozwiązać, zrób to:

W sieci głównej.config dla Twojego projektu, pod system.węzeł sieci:

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

Dodatkowo musiałem dodać to pod system.webServer node or I got a security error for my long query strings:

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

Http.usługa sys jest kodowana domyślnie maksymalnie 260 znaków na segment Url.

"segment Url" w tym kontekście jest zawartością pomiędzy znakami " / " w adresie Url. Na przykład:

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

Maksymalna dozwolona długość segmentu Url może być zmieniona za pomocą ustawień rejestru:

• Klucz: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
• wartość: UrlSegmentMaxLength
• Typ: REG_DWORD
Dane: (żądany nowy segment adresu URL maksymalna dozwolona długość, np. 4096)

Więcej o http.sys ustawienia: http://support.microsoft.com/kb/820129

Maksymalna dozwolona wartość to 32766. Jeśli podano większą wartość, zostanie ona zignorowana. (Kredyt: Juan Mendes)

Ponowne uruchomienie komputera jest wymagane, aby zmiana tego ustawienia weszła w życie. (Kredyt: David Rettenbacher, Juan Mendes)

OK więc po części napisałem to było również dlatego, że znaleźliśmy pracę wokół.

Mam nadzieję, że w przyszłości komuś się to przyda: d

Obejście pracy

Obejście jest dość proste i całkiem przyjemne.

Ponieważ wiemy, które części witryny będą musiały używać dynamicznych parametrów (a tym samym będą miały dynamiczną ścieżkę i długość), możemy uniknąć wysyłania tego długiego adresu url do ASP.NET routingu, przechwytując go zanim jeszcze uderzy ASP.NET

Wprowadź przepisywanie adresu URL IIS7(lub jakikolwiek równoważny moduł przepisywania).

Ustawiamy taką regułę:

    <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>

Zasadniczo, to co robimy, to utrzymywanie wystarczającej ilości ścieżki, aby móc nazwać właściwą trasę w dół rzeki. Reszta ścieżki URL, którą hakujemy.

Gdzie znajduje się reszta adresu URL?

Cóż, gdy reguła przepisywania jest wywoływana, moduł przepisywania adresu URL IIS7 automatycznie ustawia ten nagłówek w zapytanie:

HTTP_X_ORIGINAL_URL

HttpContext.Request.Url.PathAndQuery

Zamiast tego patrzymy na ten nagłówek:

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

The Snags

Dostęp do nagłówka

Jeśli chcesz wiedzieć, aby uzyskać dostęp do nagłówka modułu IIS7 Rewrite, możesz to zrobić na dwa sposoby:

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

Lub

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

Naprawianie Ścieżek Względnych

To, co również zauważysz, to że przy powyższej konfiguracji wszystkie ścieżki względne ulegają zerwaniu (adresy URL zdefiniowane przez "~").

Dotyczy to adresów URL zdefiniowanych za pomocą ASP.NET metody MVC HtmlHelper i UrlHelper (Jak Url.Route("Bla")).

Tutaj dostęp do ASP.NET kod MVC jest super.

W metodzie System.Web.Mvc.PathHelper.GenerateClientUrlInternal() wykonywane jest sprawdzenie, czy istnieje ten sam nagłówek modułu przepisywania adresu URL (patrz powyżej):

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

Jeśli tak się stanie, wykonywana jest pewna praca, aby zachować pochodzący adres URL.

W naszym przypadku, ponieważ nie używamy przepisywania adresów URL w "normalny" sposób, chcemy zwarcie tego procesu.

Chcemy udawać, że nie doszło do przepisania adresu URL, ponieważ nie chcemy, aby ścieżki względne były brane pod uwagę w kontekście oryginalnego adresu URL.

Najprostszym hackiem, jaki przyszło mi do głowy, było całkowite usunięcie tej zmiennej serwera, więc ASP.NET MVC nie znajdzie:

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

(zauważ, że w powyższej metodzie usuwam nagłówek z Request.ServerVariables ale nadal go zachowuję, schowanie go w Context.Items. Powodem tego jest to, że potrzebuję dostępu do wartości nagłówka później w potoku żądania.)

Mam nadzieję, że to pomoże!

Myślę, że starasz się ciężko wykorzystać GET. Spróbuj zmienić metodę żądania na POST i umieść te parametry ciągu zapytania w treści żądania.

Długi adres URL nie pomaga również w SEO, prawda?

Wygląda na to, że maksymalna długość zakodowanego adresu URL została ustalona w. NET 4.0. W szczególności istnieje obecnie web.config sekcja z:

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

Które pozwalają rozszerzyć zakres dozwolonych adresów URL.

Miałem podobny problem z maksymalną długością URL używając ASP.NET Web API 4, które generowało nieco inny błąd:

404 błąd

Poprawka dla mnie została opisana powyżej przez aktualizację sieci.config z obu następujących tagów:

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

I

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