2

この質問が漠然としすぎていないことを願っていますが、基本的なことが欠けているように感じます。これが私の状況です。各ユーザーのローカル マシン (Windows 7) で実行されるシック クライアント アプリケーションがあり、アプリケーションとやり取りするための JavaScript API を提供します。サーバーでホストされている Web アプリがありますが、localhost に対して AJAX 要求を行い、シック クライアントの JS API とやり取りします。

1 台のマシンで、Web アプリを読み込みます。localhost に対して行われるすべての AJAX リクエストは、OPTIONS プリフライト リクエストなしで行われます。JS コンソールの [ネット] タブには、作成された POST が表示され、応答が成功しています (必要なすべての CORS ヘッダーを含め、応答に含めるヘッダーをシック クライアントに伝えることができます)。

別のマシンで、同じサーバーから Web アプリを読み込みます。ただし、AJAX 要求が localhost に対して行われると、(予期される) OPTIONS 要求が行われます。残念ながら、シック クライアントは適切な Access-Control-Allow-Origin ヘッダーで応答しないため、その後の POST は実行できません。

ブラウザーは問題ではありません。最新バージョンの Firefox と Chrome をテストしましたが、マシンからは常に同じ動作が得られます。4 台のマシンでテストしました。2 台は OPTION を送信し、2 台は先行する OPTION なしで POST を送信するだけです。AJAX の宛先がオリジンと異なるかどうか、およびプリフライト リクエストを送信するかどうかは、ブラウザ次第のようです。AJAXリクエスト（localhostまたはlvh.meのいずれかへの）がWebページのソースとは異なるホスト/ドメインであるにもかかわらず、私のマシンがOPTIONSリクエストを送信しない理由を一生理解できません、別のマシンから同じページをロードすると、それらが生成されます。

これに影響を与える何らかのブラウザ設定はありますか？それともWindowsの設定？これで異なる動作が見られるのはなぜですか?

更新1:

単純化して明確にするために、machineA と machineB の 2 つのマシンがあります。どちらのマシンも、リモート サーバー example.com から Web アプリを読み込みます。どちらのマシンにも、Web サーバーと API を提供する本格的なシック アプリケーションがローカル マシンにインストールされています。example.com から読み込まれる Web アプリには、AJAX 要求を localhost に送信するための JavaScript コードが含まれているため、各ユーザーはシック クライアント アプリケーションの独自のローカル インスタンスと対話できます。localhost != example.com であるため、リクエストはクロスドメインと見なす必要があります。

machineA が標準の jQuery AJAX リクエストを localhost に送信すると (そのうち、POST のペイロードは単純に「true」であり、これによりシック クライアントは値をエコー バックします。シック クライアントが偶数かどうかを判断するためのポーリングに使用されます)。 POST は OPTIONS リクエストなしで直接行われます: POST http://localhost:4000/cgi-bin/Extensions/GeoLinkConsole/evaljs.html 200 OK 0ms 興味深いことに、その POST からの応答には Access-Control- CORS エラーを回避するために、example.com を含む Allow-Origin ヘッダー。

machineB が example.com から同じページをロードし、同じ「true」ペイロードを使用して同じ標準 jQuery AJAX リクエストを localhost に送信すると、ブラウザは OPTIONS リクエストを送信します。これは、私が実際に期待する動作です。200 OK の OPTIONS 要求応答ですが、Access-Control-Allow-Origin ヘッダーが含まれていないため、POST が通過できません。それは私の主な関心事ではなく、明らかにシック クライアントの問題です。私の最大の疑問は、OPTIONS を生成するマシンと生成しないマシンがある理由です。これが説明に役立つことを願っています。

更新 2:

リクエストヘッダーの両方のセットを含めています。実際のリクエスト ヘッダーが OPTIONS リクエストが生成されるかどうかに影響する可能性があることを知りませんでした。すぐに、OPTIONS を送信しているものには Access-Control-Request-Headers と Access-Control-Request_Method の両方が含まれていて、もう一方には含まれていないことがわかります...

OPTIONS なしで POST を送信するマシンからの要求ヘッダー:

Accept:    text/plain, */*; q=0.01
Accept-Encoding:    gzip, deflate
Accept-Language:    en-US,en;q=0.5
Content-Length:    354
Content-Type:   text/plain; charset=UTF-8
Host:    localhost:4000
Origin:    http://example.com:7802
Referer:    http://example.com:7802/
User-Agent:    Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0

OPTIONS を送信するマシンからの要求ヘッダー:

Accept:    */*
Accept-Encoding:    gzip, deflate, sdch
Accept-Language:    en-US,en;q=0.8
Access-Control-Request-Headers:    accept, content-type, x-csrftoken
Access-Control-Request-Method:    POST
Connection:    keep-alive
Host:    localhost:4000
Origin:    http://example.com:7802
Referer:    http://example.com:7802/
User-Agent:    Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

さらに、マシンには「一般的な」ヘッダー ブロックがあります。投稿したばかりの要求ヘッダーは元の POST 要求用であり、これらはプリフライト OPTIONS 要求に関連していると想定しています。

Request URL:    http://localhost:4000/cgi-bin/Extensions/GeoLinkConsole/evaljs.html
Request Method:   OPTIONS
Status Code:    200 OK
Remote Address:    127.0.0.1:4000
4

1 に答える 1

5

( How does Access-Control-Allow-Origin header work?に関する私の回答の両方の「単純ではない」ポーションを読んで、OPTIONS プリフライト リクエストが発生する一般的な理由を学ぶことに興味があるかもしれません。)

ご覧のとおり、 OPTIONS リクエストにAccess-Control-Request-Headersはヘッダー name が含まれていますx-csrftoken。これは、JavaScript が というヘッダーを送信しようとしていることを意味しますx-csrftoken。これは単純な CORS ヘッダー (つまり、、、、場合Acceptによっては) ではないためAccept-Language、最初にプリフライト OPTIONS リクエストで許可する必要があります。Content-LanguageContent-Type

通常のヘッダーに加えて、サーバーはヘッダー名を含むヘッダーでAccess-Control-Allow-OriginOPTIONS プリフライトに応答する必要があります。それが完了すると、ブラウザは実際の POST リクエストがサーバーに到達できるようにします。Access-Control-Allow-Headersx-csrftoken

または、単純x-csrftokenでないヘッダーを完全に削除すると、プリフライトは不要になります。

于 2016-01-06T17:12:08.450 に答える