概要
このドキュメントではクロスオリジン・リクエストを有効にするためのメカニズムを定義します。 リソースを取得するクロスオリジンリクエストを作成することができるAPIを定義している仕様書では、この仕様書で定義されているアルゴリズムを使用することができます。もしそのようなAPIが http://example.org 上のリソースで使用されているとき、http://hello-world.example上のリソースはこの仕様書で述べられているhttp://example.orgから上記のリソースを取得するのを許可するようなメカニズム(例： レスポンスヘッダ内で Access-Control-Allow-Origin: http://example.orgヘッダを使用するなど)を使用することもできます。
この文書の位置付け
この節は、公開時点におけるこの文書のステータスについて説明する。他の文書がこの文書に取って代わるかもしれない。W3Cが現在公開しているリストとテクニカルレポートの最新版は、W3C technical reports index at http://www.w3.org/TR/で見つけることができる。
この文書は、W3Cのメンバー、ソフトウェア開発者、および他のW3Cグループや利害関係者によって検討され、W3C勧告としてディレクターによって承認されている。これは安定した文書であり、規範的仕様として使用されてもよく、他の文書から引用してもよい。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範な開発を促進することである。 これはウェブの機能と相互運用性を強化する。
これは、Web Applications (WebApps)と Web Application Security (WebAppSec) Working Groups による WebAppSecによって公開されたCORS W3C Recommendationである。この文書がProposed Recommendationのステータスの時から変更されていない。
この文書にコメントするには、public-webappsec@w3.org （購読, アーカイブ）に電子メールを送信されたい。
この文書は2004年2月6日のW3C特許ポリシーの下で活動するグループによって作成された。W3Cは、WebAppSec WG と WebApps WG が作成した成果物に関するあらゆる開示特許の公開リストを管理する。ここには、特許開示にあたっての指示も含まれている。特許について十分に知識のある人物が、仕様にEssential Claim(s)が認められると判断した場合は、W3C特許ポリシーの第6章に従い情報を開示する必要がある。.
この勧告を公開することでW3CはCross-Origin Resource Sharing勧告内で仕様が決められている機能はHTML5 や HTTP Status Code 308などの仕様書を勧告に進めることやRFCのステータスの変更への影響を与えない。
初期版の 実装報告 が、 勧告候補版からの変更の補足とともに使用可能です。
Table of Contents
- 1 導入
- 2 準拠
- 3 用語
- 4 セキュリティに関する考慮事項
- 5 構文
- 5.1
Access-Control-Allow-Origin レスポンスヘッダ
- 5.2
Access-Control-Allow-Credentialsレスポンスヘッダ
- 5.3
Access-Control-Expose-Headers レスポンスヘッダ
- 5.4
Access-Control-Max-Age レスポンスヘッダ
- 5.5
Access-Control-Allow-Methods レスポンスヘッダ
- 5.6
Access-Control-Allow-Headers レスポンスヘッダ
- 5.7
Origin リクエストヘッダ
- 5.8
Access-Control-Request-Method リクエストヘッダ
- 5.9
Access-Control-Request-Headers リクエストヘッダ
- 6 リソースの処理モデル
- 6.1 シンプルなクロスオリジン・リクエスト、実際のリクエスト、およびリダイレクト
- 6.2 プリフライトリクエスト
- 6.3 セキュリティ
- 6.4 実装に関する考慮事項
- 7 User Agentの処理モデル
- 7.1 クロスオリジンリクエスト
- 7.1.1 Cross-Origin Requestのレスポンスを処理する
- 7.1.2 Cross-Origin Requestのステータス
- 7.1.3 ソースオリジン
- 7.1.4 シンプルなCross-Origin Request
- 7.1.5 Preflightリクエストを伴ったCross-Origin Request
- 7.1.6 プPreflight結果のキャッシュ
- 7.1.7 通常のCross-Origin Requestアルゴリズム
- 7.2 リソース共有のチェック
- 7.3 セキュリティ
- 8 CORS API Specification Advice
- 8.1 クロス オリジン要求の生成
- 8.2 同一オリジンからクロスオリジンへのリダイレクトの対応
- 8.3 クロスオリジンリクエストのステータスに関して
- 8.4 セキュリティ
- 参考文献
- 謝辞
1 導入
この節は規定ではない。
ユーザー エージェントは通常、ネットワーク要求に同一生成元制限を適用します。これらの制限により、あるオリジンのクライアント側のウェブアプリケーションが別のオリジンのデータを取得するのを制限し、現在実行されているアプリケーションのオリジンとは異なる安全でないHTTPリクエストが自動的に発信されるのを制限する。
上のパターンが適用されるユーザーエージェントには、HTTP認証や cookie 情報などのユーザーの資格情報が含まれる典型的なネットワークリクエストがあります。
この仕様は、いくつかの方法でこのモデルを拡張します。
-
レスポンスには要求の発信元のオリジンを値として持つ、リソースの内容にアクセスを許可するためのAccess-Control-Allow-Origin ヘッダを含めることができます。
ユーザー エージェントは通常、ネットワーク要求に同一生成元制限を適用します。
-
UAはsimple methodではないメソッドを使用してpreflight requestを通じてクロスオリジンのリソースがそのアクセスを受け入れるかどうか判断できる。
これは、再びユーザエージェントによって検証される。
-
サーバーサイドアプリケーションはOrigin ヘッダを通してHTTPリクエストがUAによるクロスオリジンリクエストと見なされるかどうかを判断できる。
この拡張はサーバーサイドアプリケーションがクロスオリジンリクエスト上でサービスを行うかどうかの(何も返さない等の)制限を強制できる。
この仕様は他の仕様書のビルディングブロックであり、この仕様がどのように使用されるかを定義する。CORS API と呼ばれる。例えば are Server-Sent Events や XMLHttpRequestなどがある。[EVENTSOURCE] [XHR]
CORS wiki page ではこのドキュメントのより裏側の情報を提供している。
"Hello World!" という文字列が書かれているシンプルなテキストが http://example.com/helloのパスに置かれていて http://hello-world.exampleからのアクセスを許可したい場合、この仕様で導入されたヘッダの組み合わせのレスポンスは以下のようになる。:
Access-Control-Allow-Origin: http://hello-world.example
Hello World!
以下のようにして XMLHttpRequest をクライアント側の Web application で使用し、 http://hello-world.example にアクセスすることができる:
var client = new XMLHttpRequest()
client.open("GET", "http://example.com/hello")
client.onreadystatechange = function() { /* do something */ }
client.send()
もしリソースの作者がsimple methods以外のメソッドでクロスオリジンリクエストを使用できるようにしたいと思った場合、もう少し複雑になります。その場合にはプリフライトリクエストにOPTIONSメソッドを使用してレスポンスを返し、その後(DELETE などの)使用したいメソッドを使った実際のリクエストを処理して適切なレスポンスを返す必要があります。プリフライトリクエストに対するレスポンスは、次のヘッダーを持つことができます：
Access-Control-Allow-Origin: http://hello-world.example
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: PUT, DELETE
Access-Control-Max-Ageヘッダではどれだけの期間レスポンスをキャッシュさせるかを指示することができる。 それ以降のリクエストのために、指定された時間内なら、プリフライトリクエストを作成する必要はない。Access-Control-Allow-Methodsヘッダでは実際のリクエストで使用することのできるメソッドを指定することができる。実際のリクエストのレスポンスには、以下のヘッダを含めることができる。
Access-Control-Allow-Origin: http://hello-world.example
追加のプリフライトリクエストを呼び出すのはUAが行う複雑なタスクである。 アプリケーションのホストが http://calendar.example/app に置かれており、再度 XMLHttpRequest を使用すると想定したとき、作者は以下の ECMAScript のスニペットを使用できる:
function deleteItem(itemId, updateUI) {
var client = new XMLHttpRequest()
client.open("DELETE", "http://calendar.example/app")
client.onload = updateUI
client.onerror = updateUI
client.onabort = updateUI
client.send("id=" + itemId)
}
この仕様はリソースの著者およびユーザ エージェントについて書かれている。これには — CORS API specifications — などのこの仕様書の中で定義されているcross-origin requestアルゴリズムで使用するAPIを定義する仕様書へのアドバイスや通常のクライアント側のウェブアプリケーションの作者に向けたいくつかのアドバイスが含まれている security considerationsセクションが含まれている。
セクション名や付録と同様に、この仕様書の図、例、注釈は準拠ではない。それ以外の全ては準拠するべき標準である。
この仕様書では、単語はRFC 2119の仕様で説明されているものとして解釈する。[RFC2119]
アルゴリズムの中の命令的言い回しによる要件（例えば： “先頭部のスペース文字並びを取り除く”, “false を返してこの手続きを終了” など）は、アルゴリズムを導入する際に利用されているキーワード（ “〜しなければならない”, “〜すべき”, “〜してもよい”, 等々）の意味の下で解釈されることになる。
準拠しているしているリソースはリソースに適用可能であるこの仕様書内のすべての要求リストを実装している。
準拠しているUAとはこの仕様書にリストされている全ての要求が実装されているUAのことである
仕様書のアルゴリズムから得られる結果が区別不能な場合に限り、UAとリソースの著者はこの仕様を実装するためのどんなアルゴリズムでも実装できる。(結果が同じならば別に仕様書のアルゴでなくてもよい。)
3 用語
この仕様書内のいくつかの語はThe Web Origin Concept、 HTML、
HTTPやURIの仕様のものである。[ORIGIN] [HTML] [HTTP] [URI]
用語は大抵仕様所以外の場所で定義されている。しかし、いくつかの用語はどこにも定義されていない。そのような語はここで定義されている。
二つの文字列を比較して case-sensitive であるとは、それらを比較したときコードポイントとコードポイントが正確に一致しているという意味である。
2つの文字列を比較してASCII case-insensitive であるとは、それらを比較した時、コードポイントとコードポイントが正確に一致し、なおかつその文字がU+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Zの範囲、または U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z の範囲に収まっている、という意味である。
文字列をASCII lowercaseに変換する とはU+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Zの範囲と一致する全ての文字列をそれと一致する U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z 内の文字に変換するという意味である。
語 ユーザー資格情報 はこの仕様書内ではUAがベースとなってオリジンとインタラクティブにやりとりされる前に送信される cookie、HTTP 認証、クライアント側SSL証明書の意味で使用される。特にこの語はプロキシ認証情報やOrigin ヘッダとは関係がない。[COOKIES]
語クロスオリジンは 同一オリジンではないという意味で使用される。
もし method が case-sensitiveで以下にマッチする場合、simple methodと呼ばれる:
もし ヘッダのフィールド名がASCII case-insensitiveでAccept, Accept-Language, or Content-Language にマッチする場合、 もしくはASCII case-insensitiveでContent-Typeにマッチ、なおかつヘッダフィールドの値メディアタイプ(パラメータ以外)が ASCII case-insensitive でapplication/x-www-form-urlencoded, multipart/form-data, or text/plainにマッチする場合、 そのヘッダは と呼ばれる。
もし ヘッダのフィールド名が ASCII case-insensitive で以下にマッチする場合、 と呼ばれる。
Cache-ControlContent-LanguageContent-TypeExpiresLast-ModifiedPragma
時、 ヘッダは 構文 セクションのABNFと一致した所ごとに解析されなければならない。もしヘッダがこの仕様書で述べられているどんなABNFにもマッチしない場合、と言われる。
4 セキュリティに関する考慮事項
この節は規定ではない。
セキュリティ要求と考慮事項はこの仕様書を通じて述べられている。このセクションではそれ以外のアドバイスをリスト化している。
simple cross-origin requestは、この仕様に準拠していない現在展開されているユーザエージェントによって生成されるものと一致するものとして定義されているこの仕様以外の場所で生成される シンプルなクロスオリジンリクエストリクエスト(例えばGET や POST を使用したクロスオリジン間のフォームのポスト 、もしくは script要素で生成されたクロスオリジン間の GET リクエスト等) では大抵ユーザー資格情報が含まれている。そのため、この仕様に準拠したリソースは常に資格情報を持ったシンプルなクロスオリジンリクエストに備えなければならない。
つまり、シンプルリクエストが検索以外の重要性を持つリソースは、要求の明示的に提供される内容に推測不可能なトークンを含めることを要求することによって、クロスサイトリクエストフォージェリ（CSRF）からシンプルリクエストを保護する必要がある。[CSRF]
この仕様書ではどのようにHTTPレスポンスでリソースにアクセスするために自オリジン外のアプリケーションのインスタンスが認証されるかを定義する。特定のタイプのリソースを特定の認証されたオリジンとして指定してはいけない。代わりにすべて拒否、もしくはすべて許可にすべきである。
ログインページ等の他のオリジンのアプリケーションで使用できないリソースにはAccess-Control-Allow-Originヘッダを返してはいけない。リソースは依然としてリクエストを明示的に提供している推測可能なトークンを含んだコンテンツの要求などのCSRF攻撃から守らなければいけない。このようなリソースのセキュリティのプロパティは、この仕様に準拠しているUAの影響を受けません。
-
アクセスコントロールがなく、公開されたリソースは常に安全に 値が"<c3>*</c3>"の<c1><a2>Access-Control-Allow-Origin</a2></c1>ヘッダを返すことができる。
機密性のあるコメントがなく、HTMLscript要素を使用してクロスオリジンとしてアクセスできるECMAScriptとして解析される GET レスポンスのボディは 値が"*"のAccess-Control-Allow-Originヘッダを返すことができる。[参照:http://security.stackexchange.com/questions/43936/does-returning-access-control-allow-origin-weaken-the-security-of-json-get-re/43965#43965]もし必要なら、そのようなリソースに上記のようなアクセスコントロールやCSRFプロテクションを付加することができる。
ユーザー資格情報もしくは、 オリジンヘッダを保持しているリクエストの要求には特別な配慮が必要である。
-
リクエストが検索以外の意義を持ち、Origin ヘッダが信頼できる場合、リソースは認証リクエストとリソースが入っているレスポンスへのアクセスを許可の区別に気を付ける必要がある
リクエストの許可はユーザーの権限と要求しているオリジンのみを使用して判断する必要がある。
しばしばリソースが明示的に特定のオリジンから機密情報を使用したクロスオリジンリクエストへの同意をユーザーに求めるような認証のための通過儀礼(動作)を必要とすることがあるがこれは適切である。このような場合、曖昧な許可している範囲を削除できるクロスオリジンリクエストリクエストの一環としてセキュリティトークンを明示的に渡す。以下はOAuthの例である。[OAUTH]
-
クロスオリジンリクエスト ユーザー資格情報を使用するのは次のような例の場合が適切である:
-
この仕様書で定義されている機密情報を持ったクロスオリジンリクエストはサーバー間のバックチャンネル、JSONP、クロスドキュメントメッセージング等の認証されたリソース共有の代わりの方法として使用される。[JSONP] [HTML]
この置換は、サーバー間のバックチャンネルと比較した場合、要求するオリジンがリクエストされたオリジンに対して権限を昇格させるXSS脆弱性、などのいくつかの場合において追加の攻撃する境界を露出することができてしまう。
JSONP型の機密情報クロスオリジンリクエストの代わりとして、この仕様を使用した場合、JSONP型はクロスオリジンのコードインジェクション経由で命令するのに対してクロスオリジンデータアクセスを提供するのでリクエストするアプリケーションのセキュリティに対する姿勢がかなり上昇する。
リソースのロードに依存するHTML iframe要素の中に入った資格情報付きのクロスオリジン通信技術の代替として、他のクロスオリジンサイドチャネルまたはクロスオリジン通信技術を実装する場合、この仕様はほぼ同等のセキュリティ状態を提供する。再度（また？）、完全に信頼されていないオリジンから受信したデータが期待したフォーマットおよび承認済の値に準拠しているために検証します。
/公開情報ではないユーザー固有のカスタマイズのみに使用している資格情報/を持ち検索以外の意図を持ってないリソースへのリクエストのために。その場合、特定のオリジンを制限されたアクセスは認証されたオリジンを除き、ユーザーを識別することに使用されているカスタマイズを防止することによってユーザーのプライバシー保護する。.
-
この仕様が検索以外の意図を持ったリクエストに使用されており、2つ以上のオリジンから生成されたデータ(例:別のオリジンのリソース間で編集、印刷、保存できるなど)またはそれと同等のものが含まれている場合、リクエストはomit credentials flagを設定し、リクエストのコンテンツ内で明示的に提供されているセキュリティトークンを使用して認証をしなければならない。特にもしオリジンが相互ではなく完全に信用できない場合には。
このようなマルチオリジンのシナリオでは、一つのオリジンの悪意のあるリソースがUAを混乱した代理(https://ja.wikipedia.org/wiki/Confused_deputy_problem)として登録し、悪意のあるユーザー資格情報をクロスオリジンリクエストで送信することで、権限を昇格することができるかもしれない。前述のような攻撃を避けるためには、アプリケーションがそれぞれのオリジンの特権の範囲の明示的な知識を持つように調整して、受け取ったすべてのパラメータや指示には本来オリジンが持つ権限を越えないよう暗示的な影響を保証するため、"調整"のそれぞれのステップでは注意してバリデーションしなければならない。[CONFUSED]
上記のような相互の複数のオリジンによる脆弱性を避けるのは難しく、代わりにUAのリクエストに自動的にアタッチされるユーザー資格情報、特定の機能やリクエストの明示的なコンテンツの一部として渡された認証されたリソースを指定するセキュリティトークンを使用する。OAuth again provides an example of such a pattern.
クライアント側のウェブアプリケーションの作者には cross-origin から受け取った有害かもしれないリソースを検証することを強く推奨する。
一意に特定できないホスト名や、特定のポートにマッピングされていない、必ずしも一意のオリジンを持っていないウェブアプリケーションは、この仕様書で定義されている安全機構を使用することができない。これはオリジンがスキームとホスト名とポートにより構成されているためである。
例として、URLが example.org/app-name/ であるアプリケーションが存在しており、app-nameの部分はexample.orgで実行されているほかのウェブアプリケーションと区別する必要のあるとします。また、ほかのアプリケーションはしっかりとこの仕様で定義されたメカニズムを採用することができません。
異なった オリジン にウェブアプリケーションをマッピングすることはウェブアプリケーションのセキュリティを上昇するために必要です。
5 構文
このセクションではこの仕様書で導入する新しいヘッダの構文を定義する。ここではそれぞれのヘッダの機能の短い説明も提供している。
resource processing model セクションではリソースがそれらのヘッダをレスポンス内でどのように使用するか説明する。同様に、 user agent processing model セクションではUAがどのようにそれらのヘッダを使用するか説明する。
このセクションで使用されているABNFの構文は、HTTP / 1.1からです。[HTTP]
この仕様で導入される新しいヘッダが同等の解析ルールを持つことを保障するためにHTTP/1.1 をABNFの基本とする。
HTTP/1.1 は現在暗示的にヘッダの値の定義にOWSを使用しないがここの形式ではOWSを想定している。
Access-Control-Allow-Origin ヘッダはレスポンス内の Origin リクエストヘッダの帰ってきた値 、もしくは"*"、もしくは "null"に基づきリソースが共有できるかどうか指示するものである。ABNF:
Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" origin-list-or-null | "*"
実際には、値 origin-list-or-null はより制約的である。 originsの空白区切りのリストが許可されているというより、これは単一の オリジン、もしくは文字列"null"のどちらかである。
Access-Control-Allow-Credentials ヘッダは omit credentials flag がセットされていないときにリクエストのレスポンスを公開できるかどうかを支持するものである。When part of the response to a これがpreflight requestのレスポンスであった場合、 このヘッダは 実際のリクエストに に ユーザー資格情報が存在できるかどうかについて指示するものである。ABNF:
Access-Control-Allow-Credentials: "Access-Control-Allow-Credentials" ":" true
true: %x74.72.75.65 ; "true", case-sensitive
ヘッダはどのヘッダが安全にCORS API 仕様のAPIに公開されているかを指示するものである。 ABNF:
Access-Control-Expose-Headers = "Access-Control-Expose-Headers" ":" #field-name
Access-Control-Max-Age ヘッダはどれだけの時間preflight result cacheに preflight request の結果をキャッシュできるかを指示したものである。ABNF:
Access-Control-Max-Age = "Access-Control-Max-Age" ":" delta-seconds
Access-Control-Allow-Methods ヘッダはpreflight requestのレスポンスの一部として、どのメソッドが actual requestで使用できるかを指示したものである。
The `Allow` header is
not relevant for the purposes of the CORS protocol.
ABNF:
Access-Control-Allow-Methods: "Access-Control-Allow-Methods" ":" #Method
ヘッダはpreflight requestのレスポンスの一部として、どのヘッダフィールド名が actual requestで使用できるかを指示したものである。ABNF:
Access-Control-Allow-Headers: "Access-Control-Allow-Headers" ":" #field-name
Origin ヘッダは cross-origin request や preflight request がどこから生成されているかを指示するものである。[ORIGIN]
Access-Control-Request-Method ヘッダはどのメソッドを actual request で使用するかを preflight requestで指示したものである。ABNF:
Access-Control-Request-Method: "Access-Control-Request-Method" ":" Method
ヘッダはどのヘッダを actual request で使用するかを preflight requestで指示したものである。ABNF:
Access-Control-Request-Headers: "Access-Control-Request-Headers" ":" #field-name
6 リソースの処理モデル
このセクションでは、リソースが実装する必要がある処理モデルについて説明します。リクエストの各タイプはリソースは自分自身のサブセクションで説明されている問題に対処する必要があるかもしれない。
この仕様書で説明されているリソース共有ポリシーは特定のリソースに結びついている。このセクションの目的のためにリソースは以下と結びついている(関係がある)。
-
リソースにアクセスするのを許可されている 0、もしくはそれ以上の origins から構成されている オリジンのリスト。
これには cross-origin リクエストのリソースがリソース自身にリダイレクトバックに気づくためにリソース自身の origin を含むことができる。
リソースがサポートしている0、もしくはそれ以上の メソッド から構成されている メソッドのリスト。
リソースがサポートしている0、もしくはそれ以上の ヘッダフィールド名 から構成されている 。
リソースが使用して、リソースを公開することのできる simple response headers 以外のヘッダのヘッダフィールド名から構成されている0以上の 。
supports credentials フラグはリクエスト内でリソースが user credentialsをサポートするかどうかを指示する。リソースがサポートする場合はtrueであり、それ以外の場合はfalseになる。
6.1 シンプルなクロスオリジン・リクエスト、実際のリクエスト、およびリダイレクト
simple cross-origin request や actual request のレスポンス内で、リソースがこのリソースを公開するかどうかを指示する。
もしリソースが再配置されていた場合、これは新しい URLを共有かどうか指示する。
リソースはリソース内でどの追加のヘッダを使用するか決定するために以下の一連の流れを使用しなければならない。：
もしOrigin ヘッダが存在しない場合、この一連の流れを終了する。このリクエストはこの仕様書の範囲外となる。
-
もし Origin ヘッダの値が list of origins内の何らかの値にcase-sensitive マッチ しない場合、追加のヘッダを設定してはいけない。そしてこの一連の流れをを終了する。
list of origins は無制限にすることができるため、"常に一致"が許容される。
-
もしリソースが資格情報をサポートしている場合、 単体の Access-Control-Allow-Origin ヘッダを付け加えて、値には、 Origin ヘッダの値と同等の値を書き込み。さらに単体の Access-Control-Allow-Credentials ヘッダを付け加えて、値には文字列 "true" とcase-sensitive する値を書き込む。
そうでない場合、単体の Access-Control-Allow-Origin ヘッダを付け加えて、値には Origin ヘッダの値と同等の値か、文字列"*"のどちらかを書き込む。
文字列 "*" は 資格情報をサポートしているリソースに対して使用することができない。
もし list of exposed headers が空ではない場合、1以上のi Access-Control-Expose-Headersヘッダを付け加えて list of exposed headersで与えられているヘッダフィールド名を値として用いる。
適切なヘッダを加えないことでリソースは origin が Origin ヘッダrと case-sensitiveに一致し、なおかつurlがリソースのURLと case-sensitive に一致するすべてのエントリの preflight result cache を消去することもできる。
6.2 プリフライトリクエスト
preflight request のレスポンス内で、リソースはどのメソッドとヘッダ( simple methods や simple headers以外の)を処理できるか、リソースが資格情報をサポートしているかどうかなどを決定する。
リソースはリソース内でどの追加のヘッダを使用するか決定するために以下の一連の流れを使用しなければならない。：
もしOrigin ヘッダが存在しない場合、この一連の流れを終了する。このリクエストはこの仕様書の範囲外となる。
-
もし Origin ヘッダの値がlist of origins内の値に case-sensitive マッチしなかった場合、追加のヘッダをセットせず、この一連の流れを終了する。
list of origins は無制限にすることができるため、"常に一致"が許容される。
Origin ヘッダにはUAがリダイレクトを追跡しない、単一のoriginのみ記述することができる。
-
methodを Access-Control-Request-Method ヘッダを解析した結果の値にする。
もし no Access-Control-Request-Methodヘッダが存在しなかったり解析に失敗した場合、どんな追加のヘッダも追加してはならない。その後、この一連のステップを終了する。このリクエストはこの仕様書の範囲外となる。
-
ヘッダフィールド名をAccess-Control-Request-Headersヘッダの解析した結果の値にする。
もしそこにAccess-Control-Request-Headers ヘッダが存在しなかった場合、ヘッダフィールド名を空のリストにする。
もし構文解析に失敗した場合、追加のヘッダをセットしてなならず、この一連の手順を終了する。このリクエストはこの仕様書の範囲外となる。
-
もしメソッドがlist of methods内の何かの値とcase-sensitive マッチしなかった場合、どんな追加のヘッダもセットしてはならず、この一連のステップを終了する。
list of methods は無制限にできるため、常にマッチングすることが許可される。
-
もし 何かのヘッダフィールド名 がlist of headers内のいずれかの値に ASCII case-insensitive マッチしない場合、追加のヘッダを設定してはならない。そしてこの一連の流れを終了する。
list of headers は無制限にできるため、常にマッチングすることが許可される。
-
もしリソースが資格情報をサポートしている場合、 単体の Access-Control-Allow-Origin ヘッダを付け加えて、値には、 Origin ヘッダの値と同等の値を書き込み。さらに単体の Access-Control-Allow-Credentials ヘッダを付け加えて、値には文字列 "true" とcase-sensitive する値を書き込む。
そうでない場合、単体の Access-Control-Allow-Origin ヘッダを付け加えて、値には Origin ヘッダの値と同等の値か、文字列"*"のどちらかを書き込む。
文字列 "*" は 資格情報をサポートしているリソースに対して使用することができない。
オプションとして、ＵＡがリクエストの結果をキャッシュするのを許可する秒数を値とした Access-Control-Max-Age ヘッダを加えることもできる。
-
メソッドが単純なメソッドの場合、この手順を省略することができる。
list of methods(のサブセット)から構成されている1以上のAccess-Control-Allow-Methods ヘッダを付け加える 。
<v0>メソッド</v0>が<a1>単純なメソッド</a1>の場合、リスティングする必要はないが、禁止されていない。
Since the list of methodsは無制限に値を取れるため、 Access-Control-Request-Method （サポートされている場合）で示されたメソッドを返すだけで十分です。
-
各header field-names が simple header であり、 Content-Typeがnoneならこの手順を省略することができる。
list of headers(のサブセット)から構成されている1以上のAccess-Control-Allow-Headers ヘッダを付け加える 。
ヘッダフィールド名がsimple header であり、 Content-Typeがない場合、これをリスティングする必要はない。Content-Typeはその値のサブセットとしてのみリストされ、simple headerと見なされる。
list of headerは無制限に値を取れるため、 Access-Control-Request-Headers で示されたメソッドを返すだけで十分です。
6.3 セキュリティ
この節は規定ではない。
リソースの作者には、GETやOPTIONS等のセーフメソッドによるリクエストを使うことを保証することを強く勧める。なぜならこれらのセーフメソッドは副作用を持たないため、潜在的な攻撃者がユーザーのデータを簡単に修正することができないからである。リソースがこのように設定されている場合、攻撃者は実際に害を与えるためには list of origins にいる必要があります。
In addition to checking the Originヘッダのチェックに加えて、リソースの作者には、Hostヘッダをチェックすることも強く推奨する。これはつまり、このヘッダから提供されるホスト名がリソースが提供されているサーバーのホスト名とマッチするか確認する作業である。これは、DNSリバインディング攻撃に対する保護を提供する。
リソース共有ポリシーの完全性の保護を提供するためにSSL/TLSの使用を推奨される。
6.4 実装に関する考慮事項
この節は規定ではない。
複数の Origins と共有を有効にしたいが、 "*" にはレスポンスを返したくないリソースの場合、実際には、許可したいすべての要求に応じて、 Access-Control-Allow-Origin ヘッダーを動的に生成する必要がある。結果として、そのようなリソースの作成者は、 Vary：Origin HTTPヘッダーを送信するか、またはそのような応答のキャッシングを防ぐための適切な制御指令を提供する必要があります。
7 User Agentの処理モデル
このセクションではUAが実装する必要のある処理モデルについて説明する。
simple cross-origin request has been definedこのセクションの処理モデルは、アルゴリズムがいつ呼び出されるか、および戻り値がどのように処理されるかを定義するCORS API仕様によって参照される必要がある。この処理モデルは独立して使うには適していない。
7.1 クロスオリジンリクエスト
cross-origin request アルゴリズムは以下の引数を取る:
- request URL
-
fetchedするためのURL 。
request URL はリダイレクトされた場合、修正される。
- request method
リクエストのメソッド。明示的に設定されない場合GETが設定される。
リクエストの作成者によって設定されるヘッダのリスト。明示的に設定されない場合空になる。
- request entity body
リクエストのボディ。明示的に設定されない場合空になる。
- source origin
-
リクエストの オリジン 。
いくつかのAPIの仕様のせいで、これは一般的な方法で定義するこができないため、引数として提供する必要がある。
- referrer source
-
Document もしくは URLのどちらか。Referer ヘッダを決定するために使用される。
- manual redirect flag
リダイレクト時に自動で追跡し ない場合にセットする。
- omit credentials flag
リクエスト内で user credentials が除外され、レスポンス内でクッキーが無視された場合にセットする
- force preflight flag
プリフライト リクエストが必要な場合にセットする。
cross-origin requestアルゴリズムは(アルゴリズムが)定義したネットワークAPIに対してクロスオリジンリクエストを許可するCORS API仕様を使用することができる。
CORS API 仕様はcross-origin requestに自由に制限を課すことができる。例：omit credentials flag を常にセットすることができる。
クロスオリジンリクエスト アルゴリズムが呼び出された場合、以下の手順を踏む必要がある。
-
もし何かの事情のためにUAがリクエストを送りたくない場合、このアルゴリズムを終了させて、 cross-origin request status を network errorにする。
request URL はいくつかの方法でユーザーによってブラックリスト入りされている可能性がある。
-
以下の条件が真の場合、 simple cross-origin request アルゴリズムに従う必要がある。(note:途中から？たぶん最初から。)：
それ以外の場合、cross-origin request with preflight アルゴリズムに従う必要がある。
simple なメソッドを使用して、author request headers がsimpleでないCross-origin requestsを行うとき 、リソースがそれらのヘッダを処理できることを保証するためにpreflight requestを持つ。(同様にリクエストにsimple methodではないメソッドを使用する。)
7.1.1 Cross-Origin Requestのレスポンスを処理する
UAはCORS API仕様書で定義されているAPIにさらす前に、ASCII case-insensitiveでフィールド名がAccess-Control-Expose-Headersマッチする、もしくはsimple response header以外の全てのレスポンスヘッダを除外しなければならない。
従って、XMLHttpRequest のgetResponseHeader() メソッドは上記で指示していないどんなメソッドも公開することができない。
7.1.2 Cross-Origin Requestのステータス
それぞれの cross-origin request は cross-origin requests にフックできるようにするためのAPIが使用できるCORS API 仕様を持っているcross-origin request status を持っているt。これは cross-origin requestの間、２つの異なった値を取ることができる。以下の値のいずれかの:
- preflight complete
- UAはactual requestを作成しようとしている。
- success
- リソースは共有することができる。
- abort error
- ユーザーがリクエストを中断した。
- network error
- リソースを共有することできない。DNS エラーが、 TLS ネゴシエーションの失敗、外のタイプのネットワークエラーが発生した場合などにも使用される。これにはHTTPステータスコード410のような、エラーのタイプのHTTPレスポンスは含まれていない。
7.1.3 ソースオリジン
source origin はUAがOrigin ヘッダに使用しなければならない初期のoriginである。これは、redirect stepsを踏む間に修正することができる。
7.1.4 シンプルなCross-Origin Request
このステップではUAはsimple cross-origin requestのために何をしなければならないかを以下に記述している。:
-
make a request steps を適用し、リクエストが作成されるまでの間以下の request rules を監視しなければならない。
- もしmanual redirect flag が未設定で、レスポンスのHTTPステータスコードが 301, 302, 303, 307, or 308のいづれかの場合
redirect stepsを適用する。
- もしエンドユーザーがリクエストをキャンセルした場合
abort stepsを適用する。
- ネットワークエラーが起こった場合
-
DNS エラー、 TLS ネゴシエーションの失敗、それ以外のタイプのネットワークエラーが発生した場合、 network error stepsを適用する。エンドユーザーと会話するタイプのリクエストをしてはいけない。
<s0>これにはHTTPステータスコード410のような、エラーのタイプのHTTPレスポンスは含まれていない。</s0>
- それ以外の場合
resource sharing checkを行う。もし失敗と判定された場合、network error stepsを適用するそれ以外の場合、もし判定が通った場合、このアルゴリズムを終了し、cross-origin request status を successに設定する。実際にリクエストを終了してはいけない。
7.1.5 Preflightリクエストを伴ったCross-Origin Request
特定の（この仕様書が存在する前の）UAから生成できないクロスオリジンリクエストに対してリソースを保護するため、リソースがこの仕様を認識していることを確認するためのプリフライト要求が行う。このリクエストの結果はpreflight result cacheにキャッシュされる。
このステップではUAはプリフライト付きcross-origin requestのために何をしなければならないかを以下に記述している:これは最初に preflight result cache エントリー、もしくはpreflight requestによる認証が必要な同一オリジンではないURLである。
-
もし以下の条件がtrueの場合、次のステップに進める:
それ以外の場合、preflight requestを作成する。 manual redirect flag と block cookies flag をセットして、override referrer source として referrer source を使用し、source originから、 OPTIONSメソッドを使いrequest URLにFetchする。その後、以下の追加の制約に進む：
以下の request rules をpreflight requestを作成するまでの間監視しなければならない:
- もしエンドユーザーがリクエストをキャンセルした場合
abort stepsを適用する。
- もしレスポンスのHTTPステータスコードが2XXの範囲ではない場合
-
<a1>network error steps</a1>を適用する。
ここではcache and network error stepsは実際のネットワークエラーとしては使用されない。
- ネットワークエラーが起こった場合
-
DNS エラー、 TLS ネゴシエーションの失敗、それ以外のタイプのネットワークエラーが発生した場合、 network error stepsを適用する。エンドユーザーと会話するタイプのリクエストをしてはいけない。
<s0>これにはHTTPステータスコード410のような、エラーのタイプのHTTPレスポンスは含まれていない。</s0>
ここではcache and network error stepsは実際のネットワークエラーとしては使用されない。
- それ以外(HTTPステータスコードが2xxの範囲に収まっている)
-
もしリソース共有チェック が失敗した場合、 cache and network error stepsを適用する。
methods が空のリストにする。
-
もし1以上のAccess-Control-Allow-Methodsヘッダが存在する場合、methodsの値を、このヘッダを 解析した結果にする。
もし解析に失敗した場合、cache and network error stepsを適用する。
-
もし methods がまだ空のリストであり、 force preflight flag がセットされている場合、request methodをmethodsに追加する。
これにより、force preflight flagによって発生した preflight requestsもまたキャッシュされることを保証する。
headers が空のリストにする。
-
もし一つ以上の Access-Control-Allow-Headers ヘッダが存在する場合headers の値をヘッダを解析した結果にする。
もし解析に失敗した場合、cache and network error stepsを適用する。
もしrequest methodがmethods内のメソッドにcase-sensitiveマッチせず、なおかつそれがsimple methodではない場合、cache and network error stepsを適用する。
author request headers内のそれぞれのヘッダのフィールド名が headers 内のヘッダフィールド名の一つにASCII case-insensitive マッチせず、そのヘッダがsimple headerではない場合、cache and network error stepsを適用する。
もし何らかの理由(例：ディスク容量が制限されているなど)でUAがpreflight result cacheを提供できない場合、次のステップに進む (例：actual requestなど)。
-
もし単一の Access-Control-Max-Age ヘッダがある場合、ヘッダを解析 し、max-ageを結果の値にする。
もしそのようなヘッダが存在しなかったり、１より多い数のヘッダが存在して parsing failedした場合、 max-age の値をUAの選んだ適切な値にする(0も許可される)。
もしUAが max-age フィールド値に制限を課し、max-ageがその値より大きい場合、max-ageの値を上限に設定する(max-ageの上限を超えた場合上限にする)。
-
method cache matchしたmethods内のそれぞれのメソッドはmax-ageにマッチしたエントリーのmax-age フィールド値を設定する。
method cache match が ない methods内のそれぞれのメソッドは各種のフィールドに以下の値を設定した新しいpreflight result cache のエントリーを作成する：
- origin
- source origin。
- url
- request URL。
- max-age
- The max-age.
- credentials
- もしomit credentials flagがセットされている場合、falseになる。それ以外の場合、trueになる。
- method
- The given method.
- header
- Empty.
-
header cache match した headers 内のそれぞれのヘッダは マッチしたエントリのmax-age フィールド値を max-ageに設定する。
<a1>header cache match</a1> が 無い headers 内のそれぞれのヘッダは各種のフィールドに以下の値を設定した新しいpreflight result cache のエントリーを作成する：
- origin
- source origin。
- url
- request URL。
- max-age
- The max-age.
- credentials
- もしomit credentials flagがセットされている場合、falseになる。それ以外の場合、trueになる。
- method
- Empty.
- header
- The given header.
cross-origin request statusをpreflight completeに設定する。
-
これはactual requestである。make a request stepsを適用し、リクエストを作成するまで以下の request rules を監視する。
- もしレスポンスの HTTP ステータスコードが 301, 302, 303, 307, 308のいずれかを持っている場合
cache and network error stepsを適用する。
- もしエンドユーザーがリクエストをキャンセルした場合
abort stepsを適用する。
- ネットワークエラーが起こった場合
-
DNS エラー、 TLS ネゴシエーションの失敗、それ以外のタイプのネットワークエラーが発生した場合、 network error stepsを適用する。エンドユーザーと会話するタイプのリクエストをしてはいけない。
<s0>これにはHTTPステータスコード410のような、エラーのタイプのHTTPレスポンスは含まれていない。</s0>
- それ以外の場合
resource sharing checkを行う。もし失敗した場合、cache and network error stepsを適用する。それ以外の場合、もし判定が通った場合、このアルゴリズムを終了し、cross-origin request status を successに設定する。実際にリクエストを終了してはいけない。
以下のシナリオを考えてみる：
UAは source origin http://example.org から http://blog.example/entries/hello-worldへのカスタムメソッドXMODIFY を使ったクロスオリジンリクエストを送信するために、XMLHttpRequestなどのAPIからリクエストを取得する。
UAは適切な値を持つ Access-Control-Request-Method ヘッダと Origin を含み、OPTIONS メソッドを使ったpreflight request をhttp://blog.example/entries/hello-worldに送信する。
-
このレスポンスには以下のヘッダが含まれている：
Access-Control-Allow-Origin: http://example.org
Access-Control-Max-Age: 2520
Access-Control-Allow-Methods: PUT, DELETE, XMODIFY
UAは XMODIFY メソッドを使用してリソースの共有が許可されているhttp://blog.example/entries/hello-worldに要求リクエストを送る。加えて、今から42分間は preflight request は必要ではなくなる。
7.1.6 プPreflight結果のキャッシュ
既に述べたように、cross-origin request with preflight は preflight result cacheを使用する。このキャッシュはいくつかのエントリから構成されている。それぞれのエントリは以下のフィールドから構成されている:
- origin
- source originを保持する。
- url
- request URLを保持する。
- max-age
Access-Control-Max-Ageのヘッダの値を保持する。- credentials
- もしomit credentials flagがセットされている場合、falseになる。それ以外の場合、trueになる。
- method
- もし header が空ではない場合、空になる。それ以外の場合、
Access-Control-Allow-Methods ヘッダの値になる。
- もし method が空ではない場合、空になる。それ以外の場合、
Access-Control-Allow-Methods ヘッダの値になる。
誤解の無いように言うと、method と header のフィールドは互いに排他的である。片方が空の時、もう片方が空ではない。
エントリーの主キーはmax-age field以外のすべてのフィールドから構成される。
エントリが格納されてから、max-age フィールドで指定された時間が過ぎた場合、エントリーはクリアされなければならない。エントリーはまた、下のアルゴリズムごとに追加したり削除したりすることができる。？？？キャッシュの中のアイテムが決して重複しない方法で追加したり削除することができる。
UAは max-age の指定された時間が過ぎ去る前に、キャッシュのエントリーをクリアすることができる。
しかしこれはpreflight result cacheオプションが効果的に作成されるため、UAはこれをサポートすることを強く推奨される。
7.1.7 通常のCross-Origin Requestアルゴリズム
通常の一連のステップで使用されている変数はそのステップを呼び出しているアルゴリズムの一部である。
リクエストステップが適用されたかどうかに関係なく、manual redirect flagがセットされたリファラーソースを使用して、参照元オリジンのオリジンからリクエストURLを取得し、その後、もしomit credentials flagが設定されていた場合、ブロックcookie flagを設定します。もし omit credentials flag が未設定の場合、 user credentials と author request headersを含む、 request entity bodyがエンティティボディのrequest methodを使用します
リダイレクトステップが適用されるたびに、この一連の手順に従います。
original URL をrequest URLとする。（逆か？）
request URLをURL conveyed by the Location header in the redirect response.
もし要求するURL <scheme> がサポートされていない場合、無限ループを防止する、もしくはそのほかの理由によりUAが新しいリクエストを作成したくない場合、 network error stepsを適用する。
もし要求するURLにユーザー認証情報が含まれていた場合、network error stepsを適用する。
もし現在のリソース共有チェックが失敗と判定された場合、network error stepsを適用する。
もしリクエストURLのoriginが original URL originとsame originでない場合、 set source origin に (送信時に "null" になる)globally unique identifier を設定する。
一連の 要求ルールを観察する間、透過的にリダイレクトに従う。
abort stepsが適用されるごとに、この一連のステップを呼び出しているアルゴリズムを終了し、cross-origin request statusをabort errorに設定する。
network error stepsが適用されるごとに、この一連のステップを呼び出しているアルゴリズムを終了し、cross-origin request statusをnetwork errorに設定する。
これはuser credentialsの設定には影響を与えない。例 block cookies flag が未設定の場合、クッキーがレスポンスにセットされる。
cache and network error steps が適用された場合、以下の手順に従う。
origin フィールドの値が source originと case-sensitive マッチし、url フィールドの値が request URLとcase-sensitive マッチするpreflight result cache 内のエントリーを削除する。
もしアルゴリズムが network error steps の代わりに cache and network error steps を呼び出した場合、network error steps を適用する。
以下の条件のいずれかが真であるキャッシュエントリー内の、 preflight result cacheがある場合、cache matchとなる：
There is a
method cache match
when there is a cache entry for which there is a cache match
and the method field value is a
case-sensitive match for the given method.
There is a
when there is a cache entry for which there is a cache match
and the header field value is an
ASCII case-insensitive match for the given header field
name.
7.2 リソース共有のチェック
与えられたリソースのリソース共有チェック アルゴリズムは以下の通りである。
もしリソースが0以上のAccess-Control-Allow-Origin ヘッダの値を含んでいた場合、失敗と判断しこのアルゴリズムを終了する。
もしAccess-Control-Allow-Origin ヘッダの値が文字 "*" であり、 omit credentials flag が設定されていた場合、成功と判断しこのアルゴリズムを終了する。
もしAccess-Control-Allow-Originの値がこの仕様書で定義されているOrigin ヘッダの値に case-sensitive マッチしない場合、失敗と判断しこのアルゴリズムを終了する。
もし omit credentials flag がセットされておらず、レスポンスに0以上のAccess-Control-Allow-Credentials ヘッダの値が含まれている場合、失敗と判断しこのアルゴリズムを終了する。
もし omit credentials flag がセットされておらず、レスポンスに0以上のAccess-Control-Allow-Credentials ヘッダの値が"true"にcase-sensitive マッチしない場合、失敗と判断しこのアルゴリズムを終了する。
Return pass.
オリジンのASCII serializationが文字列 "null"である場合、上記のアルゴリズムは関数でもある。
7.3 セキュリティ
この節は規定ではない。
様々な場所で、ユーザエージェントは追加の予防策を取ることができる。例えば、UAはキャッシュしたアイテムを保存することを許可しない、キャッシュのmax-ageに届く前にキャッシュしたアイテムを削除する、特定の URLsに接続しない、などである。
UAは preflight result cache を不当な長い時間にしてアイテムをキャッシュしないようにするためにmax-age に制限を課すことを推奨される。
cross-origin request アルゴリズムの最初のステップと redirect steps アルゴリズム内で示されているUAはリクエストを作成せずにアルゴリズムを終了しても良い。This could be done because e.g.:
- リソースのオリジンがブラックリストに入っている。
- リソースのオリジンがイントラネットの一部である。
- URL <scheme> がサポートサポートされていない。
httpsからhttpの(リクエスト)は許可されていない。- 証明書のエラーのため、
httpsを指定することはできない。
UAは通常レベルのセキュリティ上の決定を適用することと、その決定はリソース共有ポリシーだけに適用しないことを推奨される。例：もしUAが https スキームから http スキームに向かって発信するcross-origin request リクエストを許可しない場合、同じことをHTML img 要素にも適用することを推奨される。
8 CORS API Specification Advice
この節は規定ではない。
この仕様書ではこの仕様書を活用するAPI抜きでは実装できないリソース共有ポリシーを定義する。この仕様書はCORS API仕様書のポリシーを使用するAPIを定義する。
In case a CORS API 仕様書がポリシーを使用する複数のAPIを定義していた場合、このアドバイスはそれぞれのAPIごとに考慮する。
8.1 クロス オリジン要求の生成
全てのcross-origin リクエストがこの仕様書内のリソース共有ポリシーが適用することができるAPIのサポートを適用するために、CORS API 仕様書は cross-origin request アルゴリズムを参照し、以下の適切な値を挿入しなければならない： request URL, request method, author request headers, request entity body, source origin, manual redirect flag, omit credentials flag, and the force preflight flag.
CORS API仕様では、これらの入力変数をAPIで制御できるようになっていますが、固定値を設定することもできます。
GETメソッドを使用するリクエストのみ許可するAPIのCORS API仕様では、 request method を GETに設定し、request entity body を空にし、 source origin を適切な値に設定し、他の変数をAPIによって制御できるようにします。
8.2 同一オリジンからクロスオリジンへのリダイレクトの対応
ブラウザがsame origin セキュリティモデルに基づいており、この仕様書で概説されているポリシーはAPIがブラウザで使用することを意図しているため、このポリシーを使用するAPIは特殊な方法でcross-originリダイレクトの結果生じた同一オリジンリクエストを適切に処理しなければならない。
リダイレクト透過的に扱うAPIのために、CORS API 仕様書ではリダイレクトを「キャッチ」して、リダイレクトURL上で cross-origin request アルゴリズムを呼び出すことでこのシナリオを透過的に処理することを推奨している。
XMLHttpRequest仕様書ではこれを行う。[XHR]
8.3 クロスオリジンリクエストのステータスに関して
cross-origin request が進行するとともに、cross-origin request status が更新される。 cross-origin request statusの値に応じて異なった方法で反応する。
- preflight complete
-
preflight request後のみ、安全に公開できる機能を有効にできるようになりました。
例：XMLHttpRequestのupload progress events。
- success
-
このAPIによって共有できるレスポンスのコンテンツは、フィルタリングされてないヘッダを含める。
要求自体はまだ進行中です。例えば cross-origin request status の値がリクエストが完了したことを示しません。
- abort error
ユーザーがリクエストを中断した時の処理と似た処理です。これはnetwork errorの処理と同じ方法で処理できます。リクエストに関する情報を（オリジンに対して）明らかにしないようにしなければならない。
- network error
なにかのエラーが起きたリクエストの処理と似た処理です。リクエストに関する情報を（オリジンに対して）明らかにしないようにしなければならない。
8.4 セキュリティ
same origin リクエストと同様に、CORS API 仕様書では cross-originリクエストで作成者が設定、取得できるヘッダ、メソッド、 user credentials を適切に制限することを推奨している。
XMLHttpRequest仕様書のレビューによって、課されるべき種類の制限が適切に開始されます。[XHR]
CORS API 仕様はまた、ポートスキャンなどを防止するためにcross-origin request status が preflight complete もしくは success 状態になるまで明示的に何もしないことを保証する必要がある。
XMLHttpRequest プログレスイベントはcross-origin request statusがsuccessになった後にのみ発行される。Upload progress events は cross-origin request status が preflight complete状態になった後にのみ発行される。
参考文献
- [CONFUSED]
- (Non-normative) The Confused Deputy, Norm Hardy.
- [COOKIES]
- HTTP State Management Mechanism, Adam Barth. IETF.
- [CSRF]
- (Non-normative) Cross-Site Request Forgeries, Peter Watkins.
- [EVENTSOURCE]
- (Non-normative) Server-Sent Events, Ian Hickson. W3C.
- [HTML]
- HTML5, Berjon, Leithead, Navara, O'Connor, Pfeiffer and Hickson. W3C.
- [HTTP]
- Hypertext Transfer Protocol -- HTTP/1.1, Roy Fielding, James Gettys, Jeffrey Mogul et al.. IETF.
- [308]
- The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect), Julian Reschke. IETF.
- [JSONP]
- (Non-normative) JSONP, Bob Ippolito.
- [OAUTH]
- (Non-normative) The OAuth 1.0 Protocol, Eran Hammer-Lahav. IETF.
- [ORIGIN]
- The Web Origin Concept, Adam Barth. IETF.
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. IETF.
- [URI]
- Uniform Resource Identifier (URI): Generic Syntax, Tim Berners-Lee, Roy Fielding and Larry Masinter. IETF.
- [XHR]
- (Non-normative) XMLHttpRequest, Anne van Kesteren. W3C.
謝辞
この付録は非規定である。
The editor would like to thank
Adam Barth,
Alexey Proskuryakov,
Arne Johannessen,
Arthur Barstow,
Benjamin Hawkes-Lewis,
Bert Bos,
Björn Höhrmann,
Boris Zbarsky,
Brad Hill,
Cameron McCormack,
Collin Jackson,
David Håsäther,
David Orchard,
Dean Jackson,
Eric Lawrence,
Frank Ellerman,
Frederick Hirsch,
Graham Klyne,
Hal Lockhart,
Henri Sivonen,
Ian Hickson,
Jesse M. Heines,
Jonas Sicking,
Julian Reschke,
Lachlan Hunt,
呂康豪 (Kang-Hao Lu),
Maciej Stachowiak,
Marc Silbey,
Marcos Caceres,
Mark Nottingham,
Mark S. Miller,
Martin Dürst,
Matt Womer,
Mhano Harkness,
Michael Smith,
Mohamed Zergaoui,
Nikunj Mehta,
Odin Hørthe Omdal,
Philip Jägenstedt,
Sharath Udupa,
Simon Pieters,
Sunava Dutta,
Surya Ismail,
Thomas Roessler,
Tyler Close,
Jeff Hodges,
Vladimir Dzhuvinov,
Wayne Carr, and
Zhenbin Xu
for their contributions to this specification.
Special thanks to Brad Porter, Matt Oshry and R. Auburn, who all helped
editing earlier versions of this document.