Erreur "La ressource ne peut être trouvée" lorsqu'il y a un "point" à la fin de l'url

Question

J'utilise ASP .NET MVC Beta et j'obtiens l'erreur HTTP 404 (La ressource ne peut être trouvée) lorsque j'utilise cette url qui a un "point" à la fin :

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

Si j'enlève le point à la fin ou si le point se trouve quelque part au milieu, je n'obtiens pas l'erreur.

J'ai essayé de déboguer mais je reçois l'erreur de "System.Web.CachedPathData.GetConfigPathData(String configPath)" avant ProcessRequest dans MvcHandler.

Le "point" n'est-il pas autorisé à la fin d'une url ? Ou y a-t-il un moyen de corriger la définition de la route pour gérer cette url ?

---

En voici un exemple : J'ai une table nommée Detail1 [Id(integer), Code(string), Description(string)] qui a une relation FK avec Master1 à travers sa colonne Id. Lorsque je sélectionne un enregistrement de Master1, je sélectionne également son enregistrement Detail1 pour obtenir son champ Code. Afin de ne pas effectuer cette jointure à chaque fois (puisqu'il n'y a généralement pas qu'un seul détail, mais plusieurs), j'ai choisi de ne pas utiliser la colonne Id et j'ai fait du Code PK de Detail1.

Mais lorsque je me débarrasse de Id et que j'utilise Code comme PK, mes itinéraires commencent également à fonctionner avec le champ Code, comme par exemple : Détail1 \Edit\Code1

Ce code peut contenir n'importe quoi à l'intérieur ou à la fin, y compris DOT. Dans certains cas, je peux interdire la présence d'un DOT à la fin, mais il arrive que cela soit très significatif.

J'ai également vu ceci poste que les itinéraires peuvent être très flexibles, je ne pensais donc pas que le mien était si bizarre.

C'est pourquoi je fais quelque chose d'aussi atypique. Des suggestions ?

Et aussi pourquoi il est si bizarre d'avoir un DOT à la fin d'un url ?

Answer 1

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

<httpRuntime relaxedUrlToFileSystemMapping="true" />

Je l'ai testé et il fonctionne. Haack en donne une explication.

Answer 2

Ce problème peut être résolu de plusieurs façons dans toutes les versions d'ASP.NET à partir de la version 1.0. Je sais que cela fait deux ans que ce fil de discussion a été créé, mais quoi qu'il en soit, voici ce qu'il en est :

Cause

La création d'un gestionnaire d'erreurs personnalisé ou la configuration d'une page personnalisée dans IIS pour rediriger les messages 404 ne fonctionnera pas. La raison en est qu'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 faire correspondre le chemin d'accès à un nom de fichier (virtuel mais légal).

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

L'explorateur Windows fonctionne de la même manière. Essayez de créer un nom de fichier se terminant par un ou plusieurs points, c'est-à-dire test.txt. . Vous constaterez que le nom obtenu est text.txt .

Solution pour terminer l'URL par un point en ASP.NET

La solution est simple (une fois qu'on la connaît, elle l'est toujours). Juste avant d'envoyer ce 404, il appellera Application_PreSendRequestHeaders La conférence est un événement simple auquel vous pouvez vous inscrire en cliquant sur le lien suivant Global.asax.cs (ou l'équivalent en VB). Le code suivant renvoie 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();
    }
}

Note : ce code fonctionne également lorsque "aspx" est no de l'URL. Par exemple http://example.com/app/somepath . appellera cet événement. Notez également que certains chemins ne fonctionneront toujours pas (les chemins se terminant par plusieurs points, par une balise de hachage ou par un signe <, par exemple, provoquent une mauvaise requête de type 400). En revanche, cela fonctionne pour les chemins se terminant par un guillemet, un espace + barre oblique, ou plusieurs points séparés par des espaces.

Answer 3

Dans .NET 4.5, j'ai résolu ce problème en ajoutant "/" à la fin de l'url.

Dans votre cas, il s'agirait donc de "http://localhost:81/Title/Edit/Code1./". C'est la seule chose que j'ai faite, je n'ai pas eu à ajouter le paramètre httpRuntime.

Answer 4

Je suis allé dans IIS et j'ai mis la page d'erreur 404 en route vers mon contrôleur d'erreur personnalisé, avec l'intention d'utiliser le paramètre ReferrerURL pour obtenir l'URL qui a généré l'erreur, d'assainir l'URL en supprimant le point (.) et de la réacheminer de manière appropriée vers le contrôleur adéquat.

Mais cela ne fonctionne pas, car lorsque l'erreur 404 est générée, l'en-tête contient un ReferrerURL nul. En fait, j'ai passé en revue tous les paramètres de la requête et rien n'indique quelle URL a généré l'erreur 404, mais seulement que l'erreur a été générée.

Quelqu'un a-t-il eu plus de chance ?

Answer 5

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

J'ai échappé au point par un code ascii hexagonal.