Ich habe einige WCF-Webservices unter IIS 7.5, die korrekt auf http-Anforderungen reagieren, aber mit 404-Fehlern (nicht gefunden) antworten, wenn Methoden mit SSL aufgerufen werden.
Die Bindungen für die Site sind wie folgt:
Beim Aufruf von http://127.0.0.1:8088/Public/PublicDataService.svc erhalte ich die erwartete Antwort:
Sie haben einen Dienst erstellt.
Um diesen Dienst zu testen, müssen Sie einen Client erstellen und ihn zum Aufrufen des Dienstes verwenden. Sie können dies mit dem Tool svcutil.exe über die Befehlszeile mit der folgenden Syntax tun: etc.
Ebenso funktioniert das Aufrufen einer der Service-Methoden. Es gibt eine grundlegendste Methode namens CanConnect, die einfach "true" zurückgibt.
http://127.0.0.1:8088/Public/PublicDataService.svc/CanConnect
wahr
Bei Verwendung von https ist das Folgende das Ergebnis.
https://127.0.0.1/Public/PublicDataService.svc
Sie haben einen Dienst erstellt.
Um diesen Dienst zu testen, müssen Sie einen Client erstellen und ihn zum Aufrufen des Dienstes verwenden. Sie können dies mit dem Tool svcutil.exe über die Befehlszeile mit der folgenden Syntax tun:
https://127.0.0.1/Public/PublicDataService.svc/CanConnect
Serverfehler in der Anwendung '/ Public'.
Die Quelle kann nicht gefunden werden.
Beschreibung: HTTP 404. Die gesuchte Ressource (oder eine ihrer Abhängigkeiten) wurde möglicherweise entfernt, ihr Name wurde geändert oder ist vorübergehend nicht verfügbar. Bitte überprüfen Sie die folgende URL und stellen Sie sicher, dass sie richtig geschrieben ist.
Angeforderte URL: /Public/PublicDataService.svc/CanConnect
Versionsinformationen: Microsoft .NET Framework Version: 4.0.30319; ASP.NET-Version: 4.6.1055.0
Das hat mich völlig verblüfft, wie können die .svc-Aufrufe funktionieren, aber ihre internen Methoden geben 404? Um die Sache noch verwirrender zu machen, hat dies funktioniert ... Ich bin mir nicht einmal sicher, wann es gestoppt wurde, dh ob es einer Code-Version oder Server-Patches usw. entspricht.
Die eigentliche Konfiguration der Website lautet also:
Webservices (this is the root of the application / where the Web.Config sits)
- Public (a windows directory, no addition config)
Es gibt eine Reihe anderer Dienste, die direkt unter dem Stamm ausgeführt werden und sowohl unter http als auch unter https einwandfrei funktionieren.
Irgendwelche Ideen, was dies verursachen könnte.