前者は、多くの場合、ブラウザに遭遇における背景分離プロジェクトは、実際に2つの要求、一つの選択肢を持っていた、サーバーがPOST /パッチリクエストを送信したい、他のは、本当のポスト/パッチ要求、取得要求でありますオプション要求は発生していません。
この問題の原因は、のがプルオプション要求が破壊されている理由を見てみましょう、クロスドメインのブラウザの扱いです。
オプションの状況要求は、2つの方法で行われます。
1、バックエンドサーバへのアクセスは、HTTP通信方式をサポートしています
図2に示すように、クロスドメイン要求プリフライト要求（プリフライトリクエスト）。
プリフライトリクエストが実際に送信される要求が安全であるか否かを検出するために、ドメイン名の先頭に追加のリソースを要求する必要が最初のHTTPオプションを送信します。ブラウザの要求が開始されたプリフライトリクエスト（プリフライトリクエスト）からオプション。
プリフライトリクエストのリクエストパケットのヘッダフィールドには、集中するための2つの必要があります。
（1）アクセス制御リクエスト-方法：実際に使用するサーバーに通知HTTPリクエストの方法。
（2）アクセス制御リクエスト・ヘッダ：カスタム実施サーバー実際に要求されたヘッダーフィールドを通知します。
サーバーが原点ヘッダを追加すると同時に、クライアントは、サーバに実際の要求のアドレスを伝えます。実用的な次の要求を受け入れるかどうかを判断するために、サーバプリフライトリクエストから取得した情報に基づいて。
クライアントに通知するために、すべての有効なリクエストメソッドのために、サーバから返されたアクセス制御 - 許可 - メソッドヘッダフィールドは、すべてのカスタム許可されたヘッダフィールドのすべてのアクセス・コントロール・リクエスト・ヘッダのヘッダフィールドはクライアントに伝え返します。また、サーバは、アクセス制御、最大年齢ヘッダーフィールドを返すことがあり、再送プリフライトを要求することなく、この結果を直接使用することができ、指定された時間にブラウザを可能にします。
これは、ブラウザのリクエストから、当社の開発プロセスを開始オプションで表示されますと、上述した第2のケースです。この方法は、オプションプリフライトリクエストの一つである前に、実際には、「複雑な要求」におけるクロスドメインリクエストが発行されます。
第二に、要求がプリフライトリクエストを行わないシンプルなクロスドメインリクエストがあるときに、複雑な要求は、唯一のプリフライトリクエストとなります。
2つの方法でのクロスドメインリクエスト：単純な要求、複雑な要求。
以下のいずれかの条件が複雑な要求です。
1.削除/入れ/パッチ/ポスト。
2. JSONデータの伝送フォーマット（コンテンツタイプ：アプリケーション/ JSON）
カスタム要求ヘッダーを持つ3。
他の例は、単純な要求として理解することができます。
なぜ複雑なクロスドメインリクエストリクエストプリフライトの必要性？
複雑な要求は、データ・サーバに悪影響を及ぼす可能性があります。たとえば、削除または入れ、サーバー上のデータを変更しますので、彼らが要求する前に、サーバーを依頼する必要があり、ドメイン名がサーバーを許可、ライセンス・サーバのリストに含まれている現在のページの後、ブラウザは正式な要請を発行し、または送信しません正式な要請。