SSLを介してWebGets/WebInvokesのみを実行するWCFサービスページがあります-ローカルマシン(自己署名証明書)で正常に動作します。しかし、実稼働環境では、service.svcに到達できます(消費方法に関するメッセージが表示されます)が、service.svc/AnyRequestは404を返します。両方の環境はIIS 7.5。
トレースを有効にしましたが、サービスはメソッドリクエスト(service.svc/SomeRequestなど)をピックアップしていませんが、service.svc
を正常に処理しています。 https://computername.domain.net/path/service.svc
もリッスンしています-これは正常ですか?通常はhttps://publicfacing.com/path/service.svc
を指している必要がありますか?
また、運用サーバーがIIS内の複数のサイトをホストしていることにも注意してください。
以下は、私のweb.configのsystem.serviceModelセクションです。 SSLBehaveは here から提案されました。
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding name="TransportSecurity">
<security mode="Transport">
<transport clientCredentialType="None"></transport>
</security>
</binding>
</webHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="SSLBehave">
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="https" port="443"/>
</defaultPorts>
</useRequestHeadersForMetadataAddress>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="UserManagement.ajaxAspNetAjaxBehavior">
<webHttp defaultOutgoingResponseFormat="Json" defaultBodyStyle="Wrapped" />
</behavior>
</endpointBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
<services>
<service name="UserManagement.ajax" behaviorConfiguration="SSLBehave">
<endpoint address="" behaviorConfiguration="UserManagement.ajaxAspNetAjaxBehavior"
binding="webHttpBinding" bindingConfiguration="TransportSecurity" contract="UserManagement.ajax" />
</service>
</services>
</system.serviceModel>
いくつかのことを確認することから始めます。
幸運を!
新しく開発されたWCF Webサービスで404をヒットするたびに最初に行うことは、このタイプの呼び出しを解釈するために必要なハンドラーマッピングを確認することです。これは問題の原因であることが多いためです。この問題を回避するにはいくつかの方法があり、その多くはServiceModelReg.exe
コンソールコマンドを手動で実行する必要があります。これらは間違いなく有効な手順ですが、開発マシンに特に複雑な構成。以下に提案する解決方法は、やや長めですが、問題をより安全かつ確実に解決できるという利点があります。
インストールが完了すると、再び404エラーが発生することなくWCFサービスを実行できるようになります。
この特定の問題に関する追加情報と修正方法については、ブログで この投稿を読む をご覧ください。
同じ問題がありました。私が読んだことから、WCFはデフォルトではNT認証認証(またはHTTPContext互換)ではありません。
セクションのWCFサービスweb.configの構成ファイルにこれを追加する必要がありました。
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
あなたがしたこと、さらにこれ:
そして、実際のサービスクラスの定義については、次を追加する必要がありました。
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class DataService : IDataDeliveryServiceContract
これで問題が解決しました。
おそらく、RouteConfig.csファイルに次の行を追加します。
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");
.svcファイルがアプリケーションのルートにある限り。
WsHttpバインディングを使用して、トランスポートレベルのセキュリティを実装できます。 この記事 ;をご覧ください。あなたのバインディングでは、代わりにこの入札を試してください:
<wsHttpBinding>
<binding name="TransportSecurity">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</wsHttpBinding>
この記事では、バインディングとエンドポイントを結び付ける必要があると述べています。
前述したように、.svc拡張子service.svc
でサービスにアクセスできますが、REST format service.svc/AnyRequest
ではなく、問題は routing integration である必要があります=。
これをweb.config
に追加します
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
<handlers>
<add name="UrlRoutingHandler" preCondition="integratedMode" verb="*" path="UrlRouting.axd"/>
</handlers>
</system.webServer>
IIS 6このエラーの原因はCheck that file exists
svcのエクステンションの設定である必要があります。 "ファイルの存在をチェックがオフになっていることを確認してください。詳細は IISホストされたサービスが失敗する 。
これにこだわっている他の人を助けるために-あなたのサービス名が 完全修飾名 ではない可能性があります。
Web.configの次の設定により、HTTPS WebサイトのWCF .svc 404が修正されました。
<webHttpBinding>
<!-- https -->
<security mode="Transport">
<transport clientCredentialType = "None" proxyCredentialType="None"/>
</security>
</binding>
</webHttpBinding>