私は、クライアントが実際に使用するWCFサービスを作成しているため、クライアントはクロスオリジン要求を処理する必要があります。開発サーバーがそのような要求を受け入れることができるようにすることに問題があります。シナリオは次のとおりです。
IEでクライアントプロジェクトを実行すると、IEはプリフライトOPTIONSリクエストを送信しないため、問題はありません。Chromeただし、プリフライトOPTIONSリクエストは405メソッドを許可せず、Chromeはサービスを放棄します。以前のバージョンのChromeは、エラーが発生し、実際のPOSTリクエスト(またはGetなど...))を続行しますが、それ以降のバージョンの方が扱いにくいようです。
また、展開されたWCFプロジェクトでこれに遭遇し、OPTIONSVerbHandlerをIISのハンドラーマッピングリストの一番上に移動することで解決しました。
CORSを許可するために考えられる最も寛大なweb.config設定を使用していることを指摘しておく必要があります。たとえば、WCFプロジェクトの構成にこれがあります。
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="*" />
<add name="Access-Control-Allow-Methods" value="*" />
<add name="X-Powered-By" value="*" />
</customHeaders>
</httpProtocol>
とにかく、コードから実行されているWCFプロジェクトへのクライアントのクロスオリジンリクエストは、405エラーで失敗します。
WCFプロジェクト自体またはIIS Express 8を設定してCORSを有効にするためのヘルプはありますか?
ありがとう!
答えは、WCFがCORSプリフライトメッセージを受け入れることができるようにするために必要な構成は、IISサーバーとは関係がなく、OPTIONS動詞を使用してHTTP要求を処理するようにWCFプロジェクト自体を構成する必要があるということです。 。
短編小説:これを行うのは本当に難しいです。 WCFは、エンドポイントに関してはあらゆる業界のジャックであるため、WCFを設定して、1つ(HTTP)で非常に具体的なことを行うことはできますが、お勧めできません。実際の解決策は、HTTPのマスターでありCORSを非常に簡単に実行するように設定できるWebAPIを使用することです。
Wcfのcorsを有効にすることができます。方法がわかれば、非常に簡単です。
より一般的な質問に対するDavidGの応答から詳しく説明します "cors on IIS" 、基本的なソリューションに必要なものに非常に近い応答:
まず、.Netハンドラーの前に実行するようにOPTIONSVerbHandler
を構成します。
OPTIONSVerbHandler
を探して、上に移動します(クリック数が多い...)。<system.webServer><handlers>
の下のすべてのハンドラーを再定義することにより、web.configでこれを行うこともできます。 (<clear>
次に<add ...>
が戻ってきました。これが、IISコンソールの機能です。ちなみに、「読み取り」権限を要求する必要はありません。このハンドラー。)
次に、corsのニーズに合わせて次のようなカスタムhttpヘッダーを構成します。
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*"/>
<add name="Access-Control-Allow-Headers" value="Content-Type"/>
<add name="Access-Control-Allow-Methods" value="POST,GET,OPTIONS"/>
</customHeaders>
</httpProtocol>
</system.webServer>
この例では、web.configであるsite/app/directory上のすべてのリクエストに対するすべての応答に対してそれらを設定します。それらをいくつかのURLに制限したい場合は、それを<location>
タグに入れてください。
これらのカスタムヘッダーをIISコンソールに追加することもできます。
これは、CORSヘッダーを必要としない要求でも送信し、アプリケーションを予期しない使用法にさらす可能性があるため、基本的なソリューションです。しかし、WCFを使用すると、最も単純なもののように見えます。
MVCまたはwebapiを使用すると、代わりにOPTIONS
動詞およびcorsヘッダーをコードで処理できます(「手動」または最新バージョンのwebapiで利用可能な組み込みサポートを使用)。
Access-Control-Allow-Methods:GET、PUT、POST、DELETE
または代わりに:
Access-Control-Allow-Methods:PUT、DELETE
仕様にはGETと記載されており、POSTが暗示されているためです。
この記事の執筆時点では、仕様に含まれていても、WebブラウザがAccess-Control-Allow-Methods
またはAccess-Control-Allow-Headers
の*ワイルドカード値をサポートしているとは思わないことをお伝えしたいと思います。
仕様:
https://www.w3.org/TR/cors/
https://tools.ietf.org/html/rfc2616#section-4.2
互換性に関する注意事項(読みやすく)を参照してください。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methodshttps://developer.mozilla.org/ en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers
上記のより良い解決策の代わりに、これはあなたが許可したいすべてのヘッダーまたはメソッドを明示的に提供しなければならないことを意味します。
djo.dadof2
が言うように、これが本当に難しいかどうかはわかりません。上記の回答の1つは、IISコンソールの使用について説明していますが、問題はIIS Expressについてです。公平を期すために、OPTIONSVerbHandler
より高く、実際にはIIS Expressで機能する可能性がありますが、すべてのハンドラーをクリアして追加し直す必要があります。これには、IISどちらを追加すればよいかわからないため、難しいです。この回答から、 JQueryからWCFサービスを呼び出す:クロスオリジンOPTIONS要求でエラー400が発生します 、本当に必要なものがすべてあることがわかります。 Global.asax.cs、Application_BeginRequest
でOPTIONSリクエストを処理することです。追加しました
if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, OPTIONS");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "content-type");
HttpContext.Current.Response.End();
}
そして一緒に
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="null" />
</customHeaders>
</httpProtocol>
私のために働いたwebconfigsystem.webServer
セクションで。 Firefoxが送信しているものと一致するようにcontent-type
ヘッダーでAccess-Control-Allow-Headers
を使用し、ローカルドライブからhtmlページを開いているときにAccess-Control-Allow-Origin
でnull
を使用したことに注意してください。