Fehler "Die Ressource kann nicht gefunden werden.", wenn ein "Punkt" am Ende der URL steht

Question

Ich verwende ASP.NET MVC Beta und ich erhalte den HTTP 404 (Die Ressource kann nicht gefunden werden) Fehler, wenn ich diese URL, die einen "Punkt" am Ende hat verwenden:

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

Wenn ich den Punkt am Ende entferne oder der Punkt irgendwo in der Mitte ist, bekomme ich den Fehler nicht.

Ich habe versucht, zu debuggen, aber es bekomme ich den Fehler von "System.Web.CachedPathData.GetConfigPathData(String configPath)" vor ProcessRequest in MvcHandler.

Ist ein "Punkt" am Ende einer URL nicht erlaubt? Oder gibt es eine Möglichkeit, die Routendefinition so zu ändern, dass sie diese Url verarbeiten kann?

---

Ein Beispiel: Ich habe eine Tabelle mit dem Namen Detail1 [Id(integer), Code(string), Description(string)], die über ihre Id-Spalte eine FK-Beziehung zu Master1 hat. Immer wenn ich einen Datensatz von Master1 auswähle, wähle ich auch den zugehörigen Detail1-Datensatz aus, um das Feld Code zu erhalten. Um diese Verknüpfung nicht jedes Mal durchführen zu müssen (da es in der Regel nicht nur ein Detail gibt, sondern mehrere), verzichte ich auf die Id-Spalte und mache Code PK von Detail1.

Aber wenn ich Id loswerde und Code als PK verwende, dann beginnen meine Routen auch mit dem Code-Feld zu arbeiten, wie: Detail1 \Edit\Code1

Dieser Code kann alles Mögliche enthalten oder am Ende stehen, einschließlich DOT. Es gibt Fälle, in denen ich ein DOT am Ende verbieten kann, aber manchmal ist es wirklich sinnvoll.

Und ich habe auch dies gesehen Beitrag dass die Routen sehr flexibel sein können, so dass ich meine nicht für so seltsam halte.

Deshalb mache ich etwas so Ungewöhnliches. Irgendwelche Vorschläge?

Und warum ist es so seltsam, ein DOT am Ende einer Url zu haben?

Answer 1

Wenn Sie .NET 4.0 verwenden, können Sie dieses Flag im Abschnitt system.web Ihrer web.config setzen und es wird zugelassen:

<httpRuntime relaxedUrlToFileSystemMapping="true" />

Ich habe es getestet und es funktioniert. Haack hat eine Erklärung dazu.

Answer 2

Dieses Problem kann in jeder ASP.NET-Version ab 1.0 auf mehrere Arten gelöst werden. Ich weiß, es ist zwei Jahre nach der Erstellung dieses Threads, aber trotzdem, hier geht es:

Ursache

Das Erstellen eines benutzerdefinierten Fehler-Handlers oder das Konfigurieren einer benutzerdefinierten Seite in IIS für die Weiterleitung der 404 wird nicht funktionieren. Der Grund dafür ist, dass ASP.NET diese URL für gefährlich hält. Intern in System.Web.Util.FileUtil ruft ASP.NET eine private Methode auf IsSuspiciousPhysicalPath der versucht, den Pfad auf einen (virtuellen, aber legalen) Dateinamen abzubilden.

Wenn der resultierende legalisierte Pfad nicht mit dem ursprünglichen Pfad übereinstimmt, wird die Verarbeitung angehalten und der ASP.NET-Code gibt einen 404 zurück (er fragt nicht IIS oder die web.config nach dem benutzerdefinierten 404, sondern gibt selbst einen zurück, was es so schwierig macht, etwas dagegen zu tun).

Der Windows Explorer funktioniert auf die gleiche Weise. Versuchen Sie, einen Dateinamen zu erstellen, der mit einem oder mehreren Punkten endet, z. B. test.txt. . Sie werden feststellen, dass der resultierende Name text.txt .

Lösung für die Beendigung der URL mit einem Punkt in ASP.NET

Die Lösung ist einfach (wenn man sie einmal kennt, ist sie es immer). Kurz bevor die 404 gesendet wird, wird der Aufruf Application_PreSendRequestHeaders ein einfaches Ereignis, für das Sie sich in Global.asax.cs (oder das VB-Äquivalent). Der folgende Code gibt einen einfachen Text an den Browser zurück, aber eine Weiterleitung oder eine andere gültige Antwort ist ebenfalls möglich.

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

Hinweis: Dieser Code funktioniert auch, wenn "aspx" als no Teil der URL. D.h., http://example.com/app/somepath . wird dieses Ereignis aufrufen. Beachten Sie auch, dass einige Pfade immer noch nicht funktionieren (wenn sie mit mehreren Punkten, einem Raute-Tag oder einem <-Zeichen enden, wird eine 400- Bad Request ausgegeben). Andererseits funktioniert es, wenn der Pfad mit einem Anführungszeichen, einem Leerzeichen+Schrägstrich oder mehreren durch Leerzeichen getrennten Punkten endet.

Answer 3

Nun, in .NET 4.5 habe ich dieses Problem durch Hinzufügen von "/" am Ende der URL behoben.

In Ihrem Fall wäre es also "http://localhost:81/Title/Edit/Code1./". Das war das Einzige, was ich getan habe, ich musste keine httpRuntime-Einstellung hinzufügen.

Answer 4

Dies zu den Handlern hinzufügen

  <add name="ExtensionlessUrlHandler-Integrated-4.0-ForApi"
 path="api/*"
 verb="*"
 type="System.Web.Handlers.TransferRequestHandler"
 preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>

Answer 5

Vielleicht http://localhost:81/Title/Edit/Code1%2E funktionieren würde.

Ich habe den Punkt durch einen Hex-Ascii-Code ersetzt.