pour résoudre ceci, faites ceci:

dans le réseau racine.config pour votre projet, sous le système.nœud web:

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

de plus, j'ai dû ajouter ceci dans le système.noeud webServer ou j'ai eu une erreur de sécurité pour mes longues chaînes de requête:

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

Http.le service sys est codé avec un maximum par défaut de 260 caractères par segment D'Url.

un" segment D'Url "dans ce contexte est le contenu entre les caractères" / " dans l'Url. Par exemple:

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

la longueur maximale permise du segment D'Url peut être modifiée avec les paramètres de registre:

• clé: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
• valeur: UrlSegmentMaxLength
• Type: REG_DWORD
• Données: (votre nouveau segment D'Url désiré longueur maximale autorisée, par exemple 4096)

plus d'informations sur http.paramètres sys: http://support.microsoft.com/kb/820129

la valeur maximale autorisée est 32766. Si une plus grande valeur est spécifiée, elle sera ignorée. (Crédit: Juan Mendes)

redémarrer le PC est nécessaire pour faire un changement à ce réglage prendre effet. (Crédit: David Rettenbacher, Juan Mendes)

OK donc une partie de la raison pour laquelle j'ai posté ceci était aussi parce que nous avons trouvé un travail autour.

j'espère que cela sera utile à quelqu'un dans le futur :d

la solution

le contournement est assez simple, et il est assez agréable aussi.

étant donné que nous savons quelles parties du site devront utiliser des paramètres dynamiques (et auront donc un chemin et une longueur dynamiques), nous pouvons éviter d'envoyer ce long url to ASP.NET routage en l'interceptant avant même qu'il ne frappe ASP.NET

entrez la réécriture de L'Url IIS7 (ou tout autre module de réécriture équivalent).

nous avons mis en place une règle comme celle-ci:

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

En Gros, ce que nous faisons, c'est simplement garder assez du chemin pour pouvoir appeler la bonne route en aval. Le reste du chemin D'URL que nous sommes en train de pirater.

où va le reste de L'URL?

Eh bien, lorsqu'une règle de réécriture est lancée, le module de réécriture D'URL IIS7 définit automatiquement cet en-tête dans la requête:

HTTP_X_ORIGINAL_URL

en aval, dans la partie de l'application qui analyse le chemin dynamique, au lieu de regarder le chemin:

HttpContext.Request.Url.PathAndQuery

nous regardons cet en-tête à la place:

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

Problème résolu... presque!

Accrocs

accéder au En-tête

si vous avez besoin de savoir, pour accéder à L'en-tête du Module de réécriture IIS7, vous pouvez le faire de deux façons:

HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]

ou

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

La Fixation Des Chemins Relatifs

ce que vous remarquerez également est que, avec la configuration ci-dessus, tous les chemins relatifs se brisent (URLs qui ont été définis avec un"~").

Cela inclut les URLs définies avec le ASP.NET MVC HtmlHelper et Méthodes UrlHelper (comme Url.Route("Bla") ).

c'est là que l'accès au ASP.NET le code MVC est génial.

dans la méthode System.Web.Mvc.PathHelper.GenerateClientUrlInternal() , il y a une vérification en cours pour voir si L'en-tête de module de réécriture D'URL existe (voir ci-dessus):

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

S'il le fait, un certain travail est fait pour préserver L'URL d'origine.

dans notre cas, puisque nous n'utilisons pas la réécriture D'URL de la manière "normale", nous voulons de court-circuiter ce processus.

nous voulons prétendre qu'aucune réécriture D'URL ne s'est produite, car nous ne voulons pas que les chemins relatifs soient considérés dans le contexte de l'URL originale.

le hack le plus simple que j'ai pu imaginer était de supprimer complètement cette variable de serveur, donc ASP.NET MVC ne le trouverait pas:

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

(notez que, dans la méthode ci-dessus, j'enlève l'en-tête de Request.ServerVariables mais je le conserve toujours), je le planque dans Context.Items . La raison en est que j'ai besoin d'accéder à la valeur de l'en-tête plus tard dans le tube de requête.)

Espérons que cette aide!

je pense que vous essayez de difficilement utiliser GET. Essayez de changer la méthode request pour POST et mettez ces paramètres de chaîne de requête dans le corps de la requête.

longue URL n'aide pas SEO aussi bien, n'est-ce pas?

il apparaît que la longueur d'URL maximale codée en dur a été fixée dans .NET 4.0 . En particulier, il y a maintenant une section web.config avec:

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

qui vous permettent d'étendre la portée des URLs autorisées.

j'avais un problème similaire de longueur D'URL Max en utilisant ASP.NET Web API 4, qui a généré une erreur légèrement différente:

erreur 404

le correctif pour moi a été décrit ci-dessus en mettant à jour le Web.config avec les deux tags suivants:

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

et

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