あるプロジェクトで、さまざまな HTML5 および Javascript 要素とそれらのセキュリティについて調べており、現在は CORS について理解しようとしています。
私のテストによれば、削除すると…
<?php
header("Access-Control-Allow-Origin: *");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
?>
アクセスしようとしているページから、Chrome のコンソール ログに次の内容が表示されます。
XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.
これは正しいと理解していますが、Wireshark は戻り値に HTTP/1.1 200 OK を表示し、データには要求されているページのソースを表示します。つまり、実際に転送されているにもかかわらず、responseText が実質的に使用されるのをブロックしているのは、ブラウザと Javascript だけなのでしょうか?
コードは以下のとおりです。
function makeXMLRequest() {
xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState==4) {
alert(xmlhttp.responseText);
}
}
xmlhttp.open("GET","http://www.bla.com/index.php",true);
xmlhttp.send();
}
前もって感謝します。
ベストアンサー1
GETやPOSTのような「単純な」HTTP動詞の場合は、ページ全体が取得され、ブラウザがJavaScriptでそのコンテンツを使用するかどうかを決定します。サーバーはリクエストがどこから来たのかを知る必要はありません。ブラウザのサーバーからの応答を検査し、JS がその内容を表示することを許可されているかどうかを判断するジョブ。
PUTやDELETEのような「単純でない」HTTP動詞の場合、ブラウザはOPTIONSリクエストを使用して「プリフライトリクエスト」を発行します。その場合、ブラウザはまずドメインがそして動詞は、それぞれAccess-Control-Allow-Origin
と をチェックすることでサポートされますAccess-Control-Allow-Methods
。(「それほど単純ではないリクエストの処理「」のCORS ページ詳細については、HTML5 Rocks の を参照してください。) プリフライト レスポンスには、 に含まれる、許容される非シンプル ヘッダーもリストされますAccess-Control-Allow-Headers
。
これは、たとえJavaScriptがクロスドメインの結果を見ることができないとしても、クライアントがサーバーにDELETEリクエストを送信できるようにすると非常に悪い可能性があるためです。繰り返しますが、サーバーは一般に、リクエストが正当なドメインから来ているかどうかを確認する義務を負っていません(ただし、5月Origin
リクエストのヘッダーを使用して実行します。