Ich verwende IIS7.5, .net 4.0. Ich arbeite vor Ort.

Ich habe Application Request Routing, Web Farm Framework, WebDeploy und UrlRewrite installiert, um einen Reverse-Proxy einzurichten. Dies funktioniert zum größten Teil gut.

Ich habe zwei Websites:

DefaultWebSite (Port 80, App-Pool: Standard-App-Pool (.net 4)) undZiel (Port 8085, App-Pool: TargetAppPool (meine Identität, .net 4)).

Ich habe eine Umschreiberegel für DefaultWebSite (erstellt wie angegeben amIIS.net), der den gesamten Localhost-Verkehr (Port 80) an umleitetlocalhost: 8085 genauso wie im obigen link beschrieben. Dies funktioniert problemlos für die meisten Dokumenttypen (.aspx, .xap, .htm, .ico), aber eine Anforderung an MyService.svc schlägt fehl. Es wird ein 404 zurückgegeben.

Deutlich sein:

Wenn ich einklebelocalhost: 8085 / MyService.svc in einen browser bekomme ich die angeforderte wcf seite.

Wenn ich einklebelocalhost / MyService.svc in einen browser bekomme ich eine 404.

Wenn ich einklebelocalhost: 8085 / MyIcon.ico In einen Browser bekomme ich die angeforderte Ressource.

Wenn ich einklebelocalhost / MyIcon.ico In einen Browser bekomme ich die angeforderte Ressource.

.svc ist der einzige Dokumenttyp, den ich gefunden habe und der eine 404 zurückgibt.

Ich habe zwei wichtige Informationen.

App-Pools. Wenn ich den App-Pool der DefaultWebSite in TargetAppPool ändere, wird der Wert 404 zu 500 ("Zuordnung des Pfads '/' fehlgeschlagen"). Alle anderen Anforderungen sind erfolgreich, wenn diese Änderung vorgenommen wird. Nicht sicher, ob dies relevant ist oder nicht.

FREB-Protokoll (Failed Request Tracing). Ich habe eine Seite gefunden (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx), in dem die Schritte in einem FREB-Protokoll beschrieben werden, wenn ein URL-Umschreibevorgang erfolgreicher ist als meiner (der Vorgang schlägt später fehl). Ich konnte nicht herausfinden, wie ein FREB-Protokoll für ein erfolgreiches Umschreiben erstellt werden kann (sofern dies möglich ist), sodass ich mein FREB-Protokoll nur mit dem in diesem Blog vergleichen kann. Ich kann ihren Schritt 21 (URL_CHANGED) in meinem FREB-Protokoll sehen, aber nicht 22 (URL_REWRITE_END). Ich habe nicht genug Erfahrung mit diesen Protokollen, um etwas Wichtigeres zu bemerken (Vorschläge erwünscht).

Meine Hauptfrage ist: Weiß jemand, warum nur URLs, die .svc-Ressourcen anfordern, nicht neu geschrieben werden?

Eine zweite Frage ist: Weiß jemand, wie man ein FREB-Protokoll für eine erfolgreiche Anfrage erstellt (wenn es überhaupt möglich ist)?

Vielen Dank

Aktualisieren:

Ich habe die Architektur geändert, um mehr Informationen zu erhalten.

Ich habe die Target-Website auf einen anderen PC verschoben, auf dem ich Microsoft Network Monitor installiert habe, um den eingehenden Datenverkehr zu erfassen.

Bevor ich die Url-Rewrite-Regel geändert habe, um auf diese neue Website zu verweisen, habe ich die richtige Antwort erhalten, als ich eine Anfrage an MyService.svc auf dem neuen PC gestellt habe. Fein.

Sobald ich die Umschreiberegel geändert habe, um die Anforderung an die neue Zielwebsite weiterzuleiten, antwortet sie wie zuvor (404). Ich habe sowohl POST- als auch GET-Anfragen gestellt. Das Netzwerkmonitorprotokoll enthält keine Anzeichen für Anforderungen (alle anderen Anrufe (-200, 404 oder andere) werden in diesem Protokoll angezeigt).

Dies führt mich zu der Annahme, dass etwas mit Url-Rewrites und * .svc-Anforderungen nicht kompatibel ist. Ich habe versucht, MyService.asmx anzufordern (nachdem diese Datei erstellt wurde), und es wurde eine Seite korrekt zurückgegeben, daher ist sie auf * .svc beschränkt. Irgendwelche Ideen?