web-dev-qa-db-fra.com

ASP.net HTTP 404 - Fichier non trouvé à la place de l'exception MaxRequestLength

J'ai un contrôle de téléchargement de fichier sur ma page Web. La longueur maximale de la demande est définie sur 8 Mo (maxRequestLength = 8192). J'ai également une validation du serveur qui génère une erreur si le fichier dépasse 4 Mo. La raison pour laquelle ses 8 Mo dans la configuration est l’effet de levier offert à l’utilisateur et permet également de tester l’application.

Si je télécharge un fichier de 9 Mo, une exception est émise La longueur maximale de la demande est dépassée. , ce qui est correct et fonctionne comme prévu. Mais lorsque j'essaie de télécharger un fichier de 1 Go, il affiche un HTTP 404 - Fichier non trouvé . Quelqu'un peut-il s'il vous plaît expliquer pourquoi cela se produit et comment puis-je l'obtenir pour me lancer une exception maxRequestLength ?

J'utilise IIS6.

38
Divi

J'ai rencontré cette condition aujourd'hui (HTTP 404 lors du téléchargement de fichiers volumineux avec IIS 7), mais je pensais que j'avais défini tous les paramètres de configuration corrects. Je voulais télécharger des fichiers allant jusqu'à 300 Mo, j'ai donc défini les paramètres Web.config suivants dans un sous-dossier de l'application:

<configuration>
    <system.web>
        <httpRuntime maxRequestLength="307200" />
    </system.web>
    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits maxAllowedContentLength="314572800" />
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

Cette configuration a fonctionné en test, mais lorsque j'ai copié les fichiers mis à jour, y compris le fichier web.config sur le serveur de production, j'ai reçu l'erreur HTTP 404 lors du téléchargement d'un fichier de 90 Mo. Les fichiers plus petits sous la limite de 30 Mo applicable à l'ensemble de l'application fonctionnaient correctement. Je savais donc qu'il s'agissait d'un problème de taille de la demande.

J'ai pensé qu'il était possible que IIS ait mis en cache certains paramètres d'application et ne les ait pas mises à jour, donc j'ai recyclé le pool d'applications , après quoi tout a fonctionné comme prévu.

58
pseudocoder

C'est un peu un vieux fil, mais j'ai pensé que je devrais ajouter mes expériences avec cela.

J'ai rencontré le même problème avec les téléchargements de fichiers volumineux et l'API Web. Un 404.13 est lancé avant d’être envoyé à un contrôleur, il a donc fallu que je trouve où intervenir et que je gère cette affaire.

Ma solution était les entrées web.config suivantes:

Je traite le 404.13 en le redirigeant vers un contrôleur mvc (il pourrait s'agir d'une page Webforms de la même manière), et des erreurs 404 classiques ont touché mon itinéraire 404. il est essentiel que responseMode = "redirect" pour le 404.13

<httpErrors errorMode="Custom">
  <remove statusCode="404" subStatusCode="-1" />            
  <error statusCode="404" subStatusCode="13" path="/errors/filesize" responseMode="Redirect" />
  <error statusCode="404" path="/errors/notfound" responseMode="ExecuteURL" />      
</httpErrors>

Ensuite, dans mon contrôleur Erreurs, j'ai les éléments suivants:

public ActionResult FileSize()
{
    Response.StatusCode = 500;
    Response.StatusDescription = "Maximum file size exceeded.";
    Response.End();
    return null;
}

Encore une fois, cela pourrait être une page de formulaires Web standard.

8
ScottE

Je ne pense pas que les réponses ici expliquent pourquoi vous obtenez un 404, ils vous expliquent simplement comment résoudre le problème.

La 404 n'est pas due à une mauvaise configuration, c'est un comportement intentionnel et documenté :

Lorsque le filtrage des demandes bloque une demande HTTP car une demande HTTP dépasse les limites de la demande, IIS 7 renvoie une erreur HTTP 404 au client et consigne l'un des états HTTP suivants avec un sous-état unique identifiant le motif de la demande. a été refusé:

 Description du sous-statut HTTP 

 404.13 Longueur du contenu trop grande 
 404.14 URL trop longue 
 404.15 Chaîne de requête trop longue 

Ces sous-états permettent aux administrateurs Web d'analyser leurs journaux IIS et d'identifier les menaces potentielles.

De plus, lorsqu'une demande HTTP dépasse les limites d'en-tête définies dans l'élément <headerLimits>, IIS 7 renverra une erreur HTTP 404 au client avec le sous-statut suivant:

 Description de l’état de sous-statut HTTP 

 404.10 En-tête de demande trop long 
8
Stijn

J'ai constaté que ce problème pouvait également être dû à IIS7 (et vraisemblablement à IIS6) lorsque l'outil URLScan était installé et en cours d'exécution sur le site.

Lors du téléchargement du fichier sur un site Web, le message "Fichier ou répertoire introuvable" a été reçu. La ressource que vous recherchez a peut-être été supprimée, si son nom a été modifié ou est temporairement indisponible. "

Si le problème est causé par URLScan, si vous essayez de télécharger le fichier volumineux sur le site tout en naviguant sur le site même du serveur d'hébergement, vous recevrez un message d'erreur complet asp.net au lieu d'un 404 mentionnant URLScan Vous pouvez également vérifier si URLScan est exécuté sur votre site dans IIS7 en affichant les filtres ISAPI du site Web dans IIS. URLScan sera répertorié s'il est utilisé.

Ce problème peut être résolu en modifiant le fichier ini car URLScan se trouve à l'emplacement "% WINDIR%\System32\Inetsrv\URLscan" et en modifiant MaxAllowedContentLength. MaxAllowedContentLength est en octets.

Cela peut nécessiter un redémarrage de IIS pour prendre effet, bien que ce ne soit pas le cas lorsque je l’ai essayé moi-même avec IIS7.

http://www.iis.net/learn/extensions/working-with-urlscan/urlscan-overview

http://www.iis.net/learn/extensions/working-with-urlscan/common-urlscan-scenarios

1
wsys177

À ma connaissance, il n’existe aucun moyen de gérer avec élégance le paramètre "maxRequestLength" d’IIS. Il ne peut même pas afficher une page d'erreur personnalisée (car il n'y a pas de code HTTP correspondant auquel répondre). La seule solution consiste à définir maxRequestLength sur un nombre absurdement élevé de kilo-octets, par exemple 51200 (50 Mo), puis de vérifier ContentLength après le téléchargement du fichier (en supposant que la demande n'expire pas avant 90 secondes). À ce stade, je peux valider si le fichier <= 5 Mo et afficher une erreur conviviale.

Vous pouvez également essayer ce lien .

Vous pouvez aussi essayer quelque chose comme ça:

private void application_EndRequest(object sender, EventArgs e)
{
    HttpRequest request = HttpContext.Current.Request;
    HttpResponse response = HttpContext.Current.Response;

    if ((request.HttpMethod == "POST") &&
        (response.StatusCode == 404 && response.SubStatusCode == 13))
    {
        // Clear the response header but do not clear errors and transfer back to requesting page to handle error
        response.ClearHeaders();
        HttpContext.Current.Server.Transfer(request.AppRelativeCurrentExecutionFilePath);
    }
}
1
Scott

Vous pouvez configurer la page d'erreur par défaut dans IIS lui-même.

0
user584539

La limite de demande est un paramètre défini par IIS. Ouvrez la section Filtrage des demandes de votre site dans IIS et sélectionnez Modifier les paramètres de la demande. Pour moi, c'était aussi simple que cela.

Un guide plus détaillé de Microsoft.

https://docs.Microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/#how-to-edit-the-request-filter-feature-settings-and-request-limits

0
DarrenY