ASP.Net: HTTP 400-Bad Request Fehler beim verarbeiten http://localhost:5957/http://yahoo.com
Ich versuche etwas zu erschaffen, ähnlich wie die diggbar : http://digg.com/http://cnn.com
Ich bin mit Visual Studio 2010 und Asp-Entwicklung-server.
Jedoch komme ich nicht an die ASP-dev-Servers, die Anforderung zu verarbeiten, denn es enthält "http:" in dem Pfad. Ich habe versucht, erstellen ein HTTPModule zum umschreiben der URL in der BeginRequest , aber der event handler nicht aufgerufen, wenn die url ist http://localhost:5957/http://yahoo.com. Der event-handler wird aufgerufen, wenn die url http://localhost:5957/http/yahoo.com
Zusammenfassen
- http://localhost:5957/http/yahoo.com funktioniert
- http://localhost:5957/http//yahoo.com funktioniert nicht
- http://localhost:5957/http://yahoo.com funktioniert nicht
- http://localhost:5957/http:/yahoo.com funktioniert nicht
Irgendwelche Ideen?
Wie etwa die Kennzeichnung einer Antwort?
InformationsquelleAutor mat3 | 2009-06-04
Du musst angemeldet sein, um einen Kommentar abzugeben.
Habe ich einen Artikel geschrieben mit Stefan ' s Hilfe, die erklärt, wie dies zu tun:
Experimente in der Verrücktheit: Ermöglicht Proz., Winkel-Klammern, und andere schlimme Sachen in der ASP.NET/IIS Anforderungs-URL
InformationsquelleAutor Scott Hanselman
Vom Stefan auf die ASP.Net team: http://forums.asp.net/p/1431148/3221542.aspx
In den aktuellen Versionen von ASP.NET Urls, die Zeichen wie der Doppelpunkt, wird zurückgewiesen, als eine potentielle Bedrohung der Sicherheit. Der historische Grund dafür ist, dass die zugrunde liegenden NTFS-Dateisystem unterstützt alternate Ressource streams zugegriffen werden kann, die mit Namen wie "yourfile.txt:hiddendata.txt". Die Blockierung der Doppelpunkt von Urls verhindert, dass schlecht geschriebene Anwendungen, um ein versehentliches arbeiten mit alternativen Ressourcen-streams.
Gibt es auch eine Einschränkung in den aktuellen Versionen von ASP.NET eingehende Urls gemappt werden müssen, um die NTFS-Datei-system für die Bestimmung der verwalteten configuration data.
In ASP.NET 4 diese Beschränkungen können Optional entfernt werden. Allerdings sind diese änderungen in der Beta 2 version ASP.NET 4 - Sie sind nicht in der Beta 1. Wir haben die Url oben in diesem forum posten und bestätigt, dass Sie mit unseren internen builds von ASP.NET 4 Sie verwenden können, dass diese Art der Url und verarbeiten es ohne jede 400-Fehler.
-Stefan
InformationsquelleAutor mat3
Vom Stefan auf die ASP.Net team
Ich Schnitt den folgenden von einer bevorstehenden Was Neues Dokument abdeckt Beta 2:
ASP.NET 4 eröffnet neue Möglichkeiten für die Erweiterung des Bereichs zulässiger Anwendung von Urls. Die einfachste und nützlichste änderung ist, dass ASP.NET bietet Entwicklern die option, um längere Urls. Frühere Versionen eingeschränkt Url-Pfadlänge 260 Zeichen (die NTFS-Datei Pfad Grenze). In ASP.NET 4 haben die Entwickler die Möglichkeit der Erhöhung (oder Verringerung, wenn Sie wählen) das limit entsprechend Ihrer Anwendungen mit zwei neuen httpRuntime-Konfiguration-Attribute:
Ändern Sie den Wert für "maxRequestPathLength" um längere oder kürzere Url-Pfade (der Teil der Url, sans-Protokoll, server und query-string). Ändern Sie den Wert für "maxQueryStringLength" zu ermöglichen, länger oder kürzer Abfrage strings.ASP.NET 4 Entwickler können anpassen, die Menge der verwendeten Zeichen, indem Sie ASP.NET's Url-Zeichen überprüft. Wenn ASP.NET findet ein ungültiges Zeichen im Pfad-Teil einer Url an, er lehnt die Anfrage mit einem HTTP 400-Fehler. In früheren Versionen der Url-Zeichen überprüft wurden, begrenzt auf eine festgelegte Anzahl von Zeichen. In ASP.NET 4-Entwickler können anpassen, die Menge der Zeichen überprüft, mit einem anderen neuen httpRuntime-Konfiguration-Attribut:
Standardmäßig die "requestPathInvalidChars" - Attribut enthält sieben Zeichen als ungültig betrachtet (das kleiner-als und größer-als-Zeichen, sowie das kaufmännische und-Zeichen codiert werden, da die Konfiguration einer Xml-Datei). Entwickler können dann zu erweitern oder zu reduzieren die Menge der ungültigen Zeichen als angemessen für Ihre Anwendung gerecht zu werden. Beachten Sie, dass ASP.NET 4 wird immer noch abgelehnt werden alle Url-Pfade, die Zeichen enthalten, die im ASCII-Charakter-Bereich von 0x00-0x1F, da diese gelten als ungültige Url-Zeichen (RFC 2396 hält diese Zeichen für "ungültig" und auf Windows-Server mit IIS6 oder höher http.sys Protokoll device-Treiber automatisch ablehnt Urls, die mit diesen Buchstaben auch).
InformationsquelleAutor mat3
Ich hatte genau dieses problem bei der Schaffung einer URL shortener für ASP.net. Für das Leben von mir, ich konnte nicht die Doppelpunkt codiert in einer Weise, dass ASP-würde es akzeptieren, und zwar entweder mit HttpUtility.UrlEncode oder javascript escape() auf der client-Seite.
Meine Lösung, was zu tun ist Base64-Codierung. Dreht sich die ganze Sache in nicht-kontroversen alpha-numerics. Dann sind Sie entschlüsseln auf dem server. Ich verwendet diese Funktionen.
Auch, ich habe ein HttpModule zu sein, ausgelöst durch einen führenden Bindestrich, damit ich weiß, zu behandeln, was folgt als URL-dekodiert werden. Ping mich, wenn Sie möchten, dass weitere details.
InformationsquelleAutor Matt Sherman
Müssen Sie mit HttpUtility.UrlEncode auf Ihrem string vor der Umleitung.
digg.com/http://cnn.com
InformationsquelleAutor Dave Markle
Ich bin mir nicht sicher, was web-server digg nutzt, aber ich Wette, dies ist einfach nicht möglich mit IIS oder integrierter web server für VS. Wahrscheinlich ist es ein web-server, die modifiziert werden können, um alle Arten von verrückten URLs.
Spencer, Danke für die Festsetzung der urls. Es gibt eine Links-rechts-oben: digg.com/cttp://cnn.com. Sehr geschätzt wird.
Getan...............
InformationsquelleAutor Spencer Ruport
Dies ist nicht IIS fehlschlägt, die die ASP-Entwicklung-server. Versuchen Sie, IIS und sehen, ob es funktioniert.
Ich habe das gleiche problem mit IIS 7, also ich glaube nicht, dass es nur eine dev-server-Problem.
InformationsquelleAutor cjk
Ich bin mir ziemlich sicher, dass Sie es tun konnte, mit IIS neu zu schreiben. ASP.NET Entwicklung Server kann nicht umschreiben, soweit ich weiß, aber Sie könnten versuchen, es zu tun, indem Sie entweder IIS7 rewriter oder, wenn Sie eine frühere version haben, durch die Ionics ISAPI Rewrite Filter.
InformationsquelleAutor Tamas Czinege
Den KB-Artikel 826437 ( http://support.microsoft.com/kb/826437 ) enthält eine Antwort auf Ihre Frage
erstellen einen 32bit DWORD-Wert VerificationCompatibility = 1
Klappte es bei mir (IIS 6, ASP.NET 4), wahrscheinlich wird es auch für Sie arbeiten
InformationsquelleAutor wizzard0
Eine schnelle Lösung für die Entwicklungsumgebung:
Ändern, Web-Projekt-Eigenschaften "Verwenden des IIS-Local Server" und wählen Sie "IIS Express" (erhält die URL der VS Dev-Server).
Fügen Sie die folgende Einstellung in der Web.config innen
<system.web>
:Für die Produktion Bereitstellung, berücksichtigt die Sicherheitsaspekte erwähnt in anderen Antworten.
InformationsquelleAutor Ricardo Stuven
Ich eine ähnliche Frage beantwortet hier.
https://stackoverflow.com/a/12037000/134761
Grundsätzlich ASP.net akzeptiert nur verschlüsselte Zeichen wie Doppelpunkt nach das Fragezeichen. Zum Glück ASP.net MVC automatisch maps /api/Personen/xxxx und /api/Personen?id=xxxx gleichermaßen in die Standard-mapping, also das ist, was ich am Ende machen.
InformationsquelleAutor angularsen
Versuchen
HttpUtility.UrlPathEncode(url)
- MSDN DocsInformationsquelleAutor phill