“La ressource est introuvable.” Erreur lorsqu’il y a un “point” à la fin de l’URL

J’utilise ASP .NET MVC Beta et j’obtiens l’erreur HTTP 404 (la ressource est introuvable) lorsque j’utilise cette URL qui a un “point” à la fin:

http: // localhost: 81 / Title / Edit / Code1 .

Si je supprime le point à la fin ou si le point est quelque part au milieu, je ne reçois pas l’erreur.

J’ai essayé de déboguer mais je reçois l’erreur de “System.Web.CachedPathData.GetConfigPathData (Ssortingng configPath)” avant ProcessRequest dans MvcHandler.

Est-ce que “dot” n’est pas autorisé à la fin d’une URL? Ou existe-t-il un moyen de corriger la définition de route pour gérer cette URL?


Pour un exemple: j’ai une table nommée Detail1 [Id (entier), Code (chaîne), Description (chaîne)] qui a une relation FK avec Master1 via sa colonne Id. Chaque fois que je sélectionne un enregistrement de Master1, je sélectionne également son enregistrement Detail1 pour obtenir son champ Code. Afin de ne pas faire cette jointure à chaque fois (car il n’y a généralement pas un seul détail, il y en a plus d’un), je choisis de ne pas utiliser la colonne Id et je fais un code PK de Detail1.

Mais quand je me débarrasse de l’ID et que j’utilise Code comme PK, mes itinéraires commencent également à fonctionner avec le champ Code, comme: Detail1 \ Edit \ Code1

Ce code peut contenir n’importe quoi ou à la fin, y compris DOT. Il y a des cas où je peux interdire un DOT à la fin mais parfois c’est vraiment important.

Et j’ai aussi vu ce post que les routes peuvent être très flexibles, donc je ne pensais pas que le mien soit si étrange.

C’est pour ça que je fais quelque chose de si peu standard. Aucune suggestion?

Et aussi pourquoi il est si étrange d’avoir un DOT à la fin d’une URL?

    Si vous utilisez .NET 4.0, vous pouvez définir cet indicateur dans la section system.web de votre site web.config et il sera autorisé:

     

    Je l’ai testé et ça marche. Haack a une explication à ce sujet.

    Cela peut être résolu de plusieurs manières dans chaque version d’ASP.NET à partir de la version 1.0. Je sais que c’est deux ans après la création de ce sujet, mais de toute façon, le voici:

    Cause

    La création de votre gestionnaire d’erreur personnalisé ou la configuration d’une page personnalisée dans IIS pour la redirection du 404 ne fonctionnera pas. La raison en est que ASP.NET considère cette URL comme dangereuse. En interne, dans System.Web.Util.FileUtil , ASP.NET appelle une méthode privée IsSuspiciousPhysicalPath , qui tente de mapper le chemin vers un nom de fichier (virtuel mais légal).

    Lorsque le chemin légalisé résultant n’est pas égal au chemin d’origine, le traitement s’arrête et le code ASP.NET renvoie un 404 (il ne demande ni IIS ni le fichier web.config pour le 404 personnalisé, il en renvoie un lui-même, ce qui le rend difficile de faire quelque chose à ce sujet).

    Windows Explorer fonctionne de la même manière. Essayez de créer un nom de fichier se terminant par un ou plusieurs points, à savoir test.txt. . Vous constaterez que le nom résultant est text.txt .

    Solution pour mettre fin à l’URL dans un point dans ASP.NET

    La solution est simple (une fois que vous la connaissez, c’est toujours le cas). Juste avant d’envoyer ce 404, il appellera Application_PreSendRequestHeaders , un événement simple auquel vous pouvez vous inscrire dans Global.asax.cs (ou l’équivalent VB). Le code suivant renverra un simple texte au navigateur, mais une redirection ou toute autre réponse valide est également possible.

     protected void Application_PreSendRequestHeaders(object sender, EventArgs e) { HttpResponse response = this.Context.Response; HttpRequest request = this.Context.Request; if (request.RawUrl.EndsWith(".")) { response.ClearContent(); response.StatusCode = 200; response.StatusDescription = "OK"; response.SuppressContent = false; response.ContentType = "text/plain"; response.Write("You have dot at the end of the url, this is allowed, but not by ASP.NET, but I caught you!"); response.End(); } } 

    Remarque: ce code fonctionne également lorsque “aspx” ne fait pas partie de l’URL. Par exemple, http://example.com/app/somepath . appellera cet événement. Notez également que certains chemins ne fonctionneront toujours pas (se terminant par plusieurs points, avec un hash-tag ou un <-sign, par exemple, provoque une demande 400-Bad). Là encore, cela fonctionne pour terminer par une citation, un espace + une barre oblique ou plusieurs points séparés par des espaces.

    Eh bien, dans .NET 4.5, j’ai corrigé ce problème en ajoutant “/” à la fin de l’URL.

    Donc, dans votre cas, ce serait “http: // localhost: 81 / Title / Edit / Code1. /”. C’était la seule chose que je faisais, je n’avais pas besoin d’append le paramètre httpRuntime.

    append ceci aux gestionnaires

        

    Peut-être que http://localhost:81/Title/Edit/Code1%2E fonctionnerait.

    J’ai échappé à la période avec un code ascii hexadécimal.

    Pourquoi ne pouvez-vous pas avoir une adresse URI terminée par un point?

    Un URI étant une demande de ressource et un impératif historique existe sur tous les systèmes d’exploitation pertinents, le caractère point est le séparateur d’extension . Le dernier point est traité comme désignant une extension de fichier, donc la terminaison de point n’aura aucun sens.

    A lire également:

    • La RFC1738
    • RFC3986