私は職場で内部のWebアプリケーションに取り組んでいます。 IE10では、リクエストは正常に機能しますが、Chromeでは、すべてのAJAXリクエスト(多くあります)は、定義したメソッドではなくOPTIONSを使用して送信されます。技術的には、私の要求は「クロスドメイン」です。サイトはlocalhost:6120で提供され、AJAXリクエストを作成しているサービスは57124にあります。 この閉じたjqueryバグ は問題を定義していますが、実際の修正ではありません。
Ajaxリクエストで適切なhttpメソッドを使用するにはどうすればよいですか?
編集:
これは、すべてのページのドキュメントロードにあります。
jQuery.support.cors = true;
そして、すべてのAJAXは同様に構築されます:
var url = 'http://localhost:57124/My/Rest/Call';
$.ajax({
url: url,
dataType: "json",
data: json,
async: true,
cache: false,
timeout: 30000,
headers: { "x-li-format": "json", "X-UserName": userName },
success: function (data) {
// my success stuff
},
error: function (request, status, error) {
// my error stuff
},
type: "POST"
});
Chromeは CORS ヘッダーを検索するリクエストをプリフライトしています。要求が受け入れ可能であれば、実際の要求を送信します。このクロスドメインを行っている場合は、単にそれを処理するか、クロスドメイン以外のリクエストを作成する方法を見つける必要があります。これがjQueryバグが修正されないためクローズされた理由です。これは仕様です。
単純なリクエスト(前述)とは異なり、「プリフライト」リクエストは、実際のリクエストが安全に送信できるかどうかを判断するために、まずOPTIONSメソッドによってHTTPリクエストを他のドメインのリソースに送信します。クロスサイトリクエストは、ユーザーデータに影響を与える可能性があるため、このようにプリフライトされます。特に、リクエストは次の場合にプリフライトされます。
- GET、HEAD、またはPOST以外のメソッドを使用します。また、POSTを使用して、application/x-www-form-urlencoded、multipart/form-data、またはtext/plain以外のContent-Typeでリクエストデータを送信する場合、 POSTリクエストがapplication/xmlまたはtext/xmlを使用してXMLペイロードをサーバーに送信する場合、リクエストはプリフライトされます。
- リクエストにカスタムヘッダーを設定します(たとえば、リクエストはX-PINGOTHERなどのヘッダーを使用します)
リクエストデフォルトのポート80/443で送信されないこのAjax呼び出しは自動的にクロスオリジンリソース(CORS)リクエストと見なされます、つまりリクエストが自動的にサーバー/サーブレット側でCORSヘッダーをチェックするOPTIONSリクエストを発行します。
設定しても
crossOrigin: false;
または省略しても。
その理由は、単にlocalhost != localhost:57124
であるためです。ポートなしでlocalhost
のみに送信してみてください-要求されたターゲットに到達できないため、失敗しますただし、ドメイン名が等しい場合は注意してください POSTの前にOPTIONSリクエストなしでリクエストが送信されます。
私はケビンBに同意します、バグレポートはそれをすべて言います。クロスドメインajax呼び出しを試みているようです。同じOriginポリシーに慣れていない場合は、ここから開始できます: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_Origin_policy_for_JavaScript 。
これがクロスドメインajax呼び出しを意図していない場合は、ターゲットURLを相対的にして問題が解決するかどうかを確認してください。 JSONPを本当に必死に見ているのに注意してください、混乱が潜んでいます。本当にあなたを助けるために私たちにできることはあまりありません。
私の場合、AWSがホストするAPI(API Gateway)を呼び出しています。 API自身のドメイン以外のドメインからAPIを呼び出そうとしたときにエラーが発生しました。私はAPI所有者であるため、 Amazon Documentation で説明されているように、テスト環境でCORSを有効にしました。
プロダクションでは、リクエストとAPIが同じドメインにあるため、このエラーは発生しません。
私はそれが役立つことを願っています!
可能であれば、別の名前で通常のGET/POSTを介してパラメーターを渡し、サーバー側のコードに処理させます。
CORSをバイパスするために自分のプロキシで同様の問題が発生し、ChromeでPOST-> OPTIONの同じエラーが発生しました。私の場合はAuthorization
ヘッダーでした(ここでは"x-li-format"
と"X-UserName"
)。ダミー形式(GETのAuthorizatinJack
など)で渡すことになり、プロキシを作成するときにプロキシのコードを変更しました宛先への呼び出し。これはPHPにあります。
if (isset($_GET['AuthorizationJack'])) {
$request_headers[] = "Authorization: Basic ".$_GET['AuthorizationJack'];
}
「プリフライト」リクエストは、実際のリクエストが安全に送信できるかどうかを判断するために、最初にOPTIONSメソッドによって他のドメインのリソースにHTTPリクエストを送信します。クロスサイトリクエスト
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
よく似た問題が発生しました。 Firefoxではすべてが正常に機能し、Chromeでは失敗する理由を理解するために、ほぼ半日を費やしました。私の場合は、リクエストヘッダーのフィールドが重複している(または入力ミスの可能性がある)ためです。
@ -Dark Falconによる answered のように、Iは単にそれを処理しました。
私の場合、node.jsサーバーを使用しており、存在しない場合はセッションを作成しています。 OPTIONSメソッドにはセッションの詳細が含まれていないため、POSTメソッドのリクエストごとに新しいセッションを作成することになりました。
したがって、create-session-if-not-existのアプリルーチンで、メソッドがOPTIONS
かどうかを確認するチェックを追加しました。そうであれば、セッション作成部分をスキップします。
app.use(function(req, res, next) {
if (req.method !== "OPTIONS") {
if (req.session && req.session.id) {
// Session exists
next();
}else{
// Create session
next();
}
} else {
// If request method is OPTIONS, just skip this part and move to the next method.
next();
}
}