Ich aktualisiere unsere Anwendung mit einem internen Webserver von .NET 2.0 auf .NET 4.0.
Ich bearbeite eine Anfrage mit einem Objekt HttpListenerWorkerRequest , das die Klasse HttpWorkerRequest erweitert, und erstellt eine Anfrage, die GetRawUrl() eine URL im Format http://localhost:82/Default.aspx zurückgibt.
In .NET 2.0 funktioniert das Senden an HttpRuntime.ProcessRequest(httpListenerWorkerRequest) ohne Probleme, aber in .NET 4.0 bekomme ich eine Webseite mit dem nichts als dem Text "Bad Request" darauf.
Knacken open HttpRuntime , ich kann sehen, dass Schlechte Anforderungen von ProcessRequestInternal(HttpWorkerRequest wr) , eine private Methode, die versucht, einen HttpContext zu erstellen, geworfen werden.
Ich habe es selbst versucht:
%Vor%Pre-update (.NET 2.0), es baut gut, post-update (.NET 4.0), ich bekomme eine System.ArgumentException, dass
The relative virtual path 'http:/localhost:82/Default.aspx' is not allowed here , geworfen bei
Was hat sich in .NET geändert, um dies zu verursachen, und was kann ich tun, um es zu umgehen?
BEARBEITEN Ich habe gerade bemerkt, dass dem nicht erlaubten http: ein einfacher Schrägstrich folgt, kein Double, obwohl GetRawUrl () in der Anfrage sicherlich ein Double zurückgibt.
Ich bin nicht 100% sicher, dass dies die "exakte Antwort" ist, aber sieht mir sehr nahe - und es gibt noch mehr zu schreiben ...
Es scheint ein breaking change einer Sorte in der Klasse VirtualPath zu sein - und es ist begründet, wie sie nach illegal characters suchen. (Außerdem können Sie die 'VirtualPath-Quelle' nach einer .NET 4-Version suchen).
Innerhalb von VirtualPath.Create wird eine Überprüfung für 'ungültige virtuelle Pfadzeichen' aufgerufen.
Es geht zuerst in die Registrierung (" HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ASP.NET ", " VerificationCompatibility ") - um zu sehen, ob der compatibility -Modus 'illegal ist Zeichen sollten verwendet werden.
Darauf basierend - ich vermute (ich habe keine Möglichkeit, das zu überprüfen gerade jetzt) - das wenn Sie den obigen Registrierungswert (int) auf
1setzen - Sie sollten Ihre Methoden mitthe old wayarbeiten lassen und keine anderen zusätzlicher Aufwand. Hinweis: Ein IIS- (oder Hostprozess) Neustart ist möglicherweise erforderlich, wie in einem der Links vorgeschlagen
Und dann, basierend auf diesem Registry-Flag, hat es einen dieser beiden ...
verwendet %Vor% Das scheint Ihre Geschichte ziemlich gut zu beschreiben, da Ihr Pfad mit der Bezeichnung "port" tatsächlich illegal für den neuen Standard ist.
(Aktualisierung basierend auf Kommentaren und der Lösung, die es gelöst hat)
Das ist mein Verständnis davon, was im Inneren vor sich geht:
1) Lösung für vor .NET 4.0 war der Schlüssel VerificationCompatibility (siehe oben).
2) Mit .NET 4.0 wird die interne Behandlung und Fixierung von URL-Pfaden robuster gemacht. Und funktioniert in den meisten Fällen gut. Kurz gesagt, Alle Pfade werden fixiert und normalisiert, bevor VirtualPath.Create eingegeben wird - und Ihr http://... wird zu einem erwarteten absoluten Pfad /Default.aspx .
Wenn Sie jedoch HttpWorkerRequest (anstelle von Anfrage / Antwort usw.) angeben, wird raw Url direkt aus worker - übernommen und die Verantwortung für die Bereitstellung der korrekten und normalisierten Pfade liegt bei Ihre Worker-Anfrage . (Dies ist immer noch ein bisschen zweifelhaft, und sieht aus wie ein Bug oder schlechte Handhabung intern).
So reproduzieren Sie das Problem:
%Vor% Gibt den Fehler The relative virtual path 'http:/localhost:82/Default.aspx' is not allowed here.
Das Update:
%Vor%Und ein Teil der Forschung zu diesem Thema basiert auf dem Schlüsselwort
VerificationCompatibility in der Registry, das der Schlüssel dazu zu sein scheint.
kaufmännisches Und-Zeichen in URL filename = schlechte Anfrage
Konfigurieren Sie IIS, um URL mit Sonderzeichen zu akzeptieren ...
Für 32 vs 64 Unterschied in der Registry
Und hier ist eine ähnliche Sache von Microsoft - aber was scheint ein "Hotfix" für "2.0", d. h. nicht für Sie - aber nur als etwas offizielles in dieser Zeile anhängen.
FIX: Fehlermeldung "HTTP 400 - Ungültige Anforderung" in .NET Framework 1.1 Update: Fehlermeldung, wenn Sie versuchen, eine ASP.NET 2.0-basierte Webseite zu besuchen: "HttpException (0x80004005 ): '/HandlerTest/WebForm1.aspx/a:b' ist kein gültiger virtueller Pfad "
ASP. NET 2.0 x64 - Sie können HTTP 400 Bad Request oder Fehler erhalten, wie in KB 932552 oder 826437 erwähnt
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ASP.NET
DWord-Wertname: VerificationCompatibility-Wert: 1
Hier ist meine Meinung dazu. Es enthält immer noch einige Rätselraten, aber ich werde einen Test einschließen, den Sie machen können, um diese Hypothese zu beweisen oder zu widerlegen.
Der Stack-Trace zeigt ClientFilePath.get als Ursprung der Ausnahme an. Es sieht so aus:
Erzeugt ein VirtualPath und erlaubt nur absolute Werte. http://localhost:82/Default.aspx ist ein relativer Pfad, da er nicht mit einem Schrägstrich beginnt. In diesem Kontext ist nicht eine URL, weil sie nicht als solche interpretiert wird.
So verweigert VirtualPath.Create diesen Pfad verständlicherweise. Ich weiß nicht, warum .NET 2.0 dies erlaubte, aber .NET 4.0 erfordert einen absoluten Pfad und entsprechend dem Code ist das nicht konfigurierbar.
Ich habe noch nie gesehen, dass HttpRequest.RawUrl eine URL zurückliefert. Nach meiner Erfahrung sollte es einen absoluten Pfad wie /Default.aspx zurückgeben. Wenn Sie den Host und den Port einstellen wollen, müssen Sie andere Möglichkeiten finden, dies zu tun.
Das Problem ist also, nicht http://localhost:82/Default.aspx , sondern /Default.aspx zu verwenden. Würde das für dich funktionieren?
Tags und Links .net httpruntime