目標
目標は、~web~platform全体にわたる~fetchingを統一して、それが孕む あらゆるものに,一貫した取扱いを供することである — 次に挙げるものも含め: ◎ The goal is to unify fetching across the web platform and provide consistent handling of everything that involves, including:
- 各種~URL~scheme
- ~redirect
- 非同一-生成元( `cross-origin^en, “生成元~間をまたがる” )の意味論 【`同一-生成元$( `same-origin^en )の否定でもある。】
- CSP `CSP$r 【 “`Content Security Policy^en” ( “内容保安施策” )の略語。この訳では、一貫してこの略語を利用する。】
- ~sw `SW$r
- 混在d内容( `Mixed Content^en ) `MIX$r
- `Referer$h ~header `REFERRER$r
そうするため、元々は `Web Origin Concept^cite `ORIGIN$r にて定義された~HTTP `Origin$h ~headerの意味論にも取って代わる。 ◎ To do so it also supersedes the HTTP `Origin` header semantics originally defined in The Web Origin Concept. [ORIGIN]
1. 序
資源の~fetchingは、高~levelから見れば,要請を送ったら応答が返ってくる,それなりに単純な演算である。 しかしながら,その演算の詳細は、様々なものと~~複雑に入り組んでいるため 注意深く書き下ろされていなかったのが常であり,~APIの~~世代ごとに異なっている。 ◎ At a high level, fetching a resource is a fairly simple operation. A request goes in, a response comes out. The details of that operation are however quite involved and used to not be written down carefully and differ from one API to the next.
数多くの~APIが資源を~fetchする能を供する — 例えば ⇒# ~HTMLの `img$e, `script$e 要素 / ~CSSの `cursor^css, `list-style-image^css / ~JS~APIの `navigator.sendBeacon()$m, `self.importScripts()$m ◎ Numerous APIs provide the ability to fetch a resource, e.g. HTML’s img and script element, CSS' cursor and list-style-image, the navigator.sendBeacon() and self.importScripts() JavaScript APIs.\
~Fetch標準は、これらの特能~用に,統一された~architectureを供する — それらすべてが、~redirectや CORS ~protocolなど,~fetchingの様々な側面に関して一貫するように。 ◎ The Fetch Standard provides a unified architecture for these features so they are all consistent when it comes to various aspects of fetching, such as redirects and the CORS protocol.
~Fetch標準は、 `fetch()$m ~JS~APIも定義する。 それは、~networkingの機能性のほとんどを,~~相応に低~levelな抽象-化の下で公開する。 ◎ The Fetch Standard also defines the fetch() JavaScript API, which exposes most of the networking functionality at a fairly low level of abstraction.
【この訳に特有な表記規約】
この訳の,~algoや定義の記述に利用されている各種記号( ~LET, コレ, ε, ~IF, ~THROW, 等々)の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。
この仕様の外で定義されている,ほとんどの[ ~HTTP~header名 / ~HTTP~method名 / ~HTTP応答~状態s~code / `~CSP指令$ ]には、それを定義する仕様(和訳)への~linkを追加している(これらの~linkは、原文~仕様にはあてがわれていない)。
2. 基盤
この仕様は Infra Standard に依存する。 `INFRA$r ◎ This specification depends on the Infra Standard. [INFRA]
この仕様は、次に挙げる標準による各種用語を利用する ⇒ `ABNF$r `ENCODING$r `HTML$r `HTTP$r `WEBIDL$r `MIMESNIFF$r `STREAMS$r `URL$r ◎ This specification uses terminology from the ABNF, Encoding, HTML, HTTP, IDL, MIME Sniffing, Streams, and URL Standards. [ABNF] [ENCODING] [HTML] [HTTP] [WEBIDL] [MIMESNIFF] [STREAMS] [URL]
`~ABNF@ は、~HTTP, および `RFC7405$r により増補された~ABNFを意味する(特に,~HTTPによる # の追加 【`~ABNF~list拡張$】 )。 ◎ ABNF means ABNF as augmented by HTTP (in particular the addition #) and RFC 7405. [RFC7405]
`資格証@ は、[ ~HTTP~cookie / ~TLS~client証明書 / (~HTTP認証~用の)`認証~entry$ ]の総称である。 `COOKIES$r `TLS$r `HTTP-AUTH$r ◎ Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication). [COOKIES] [TLS] [HTTP-AUTH]
`~fetch~params@ は、次に挙げる`~item$sctからなる`構造体$であり,`~fetch$~algoの内部状態管理~用に利用される: ◎ A fetch params is a struct used as a bookkeeping detail by the fetch algorithm. It has the following items:
- `要請@fP ◎ request
- `要請$ ◎ A request.
- `要請の本体を処理する@fP (既定は ~NULL ) ◎ process request body (default null)
- `要請の本体の終端を処理する@fP (既定は ~NULL ) ◎ process request end-of-body (default null)
- `応答を処理する@fP (既定は ~NULL ) ◎ process response (default null)
- `応答の本体の終端を処理する@fP (既定は ~NULL ) ◎ process response end-of-body (default null)
- ~NULL /~algo 【これらの~algoがとる引数については、`~fetching$を見よ。】 ◎ Null or an algorithm.
- `~taskの行先@fP (既定のは ~NULL ) ◎ task destination (default null)
- ~NULL/`大域~obj$/`並列~queue$ ◎ Null, a global object, or a parallel queue.
`~fetch~taskを~queueする@ ときは、所与の ( `大域~obj$/`並列~queue$ %~taskの行先, ~algo %~algo ) に対し, %~taskの行先 に応じて: ◎ To queue a fetch task, given an algorithm algorithm, a global object or a parallel queue taskDestination, run these steps:
- `並列~queue$である ⇒ %~taskの行先 に`手続きを~enqueueする$( %~algo ) ◎ If taskDestination is a parallel queue, then enqueue algorithm to taskDestination.
- `大域~obj$である ⇒ `大域~taskを~queueする$( `~network用~task源$, %~taskの行先, %~algo ) ◎ Otherwise, queue a global task on the networking task source with taskDestination and algorithm.
%~algo の内容がその場で与えられる場合、これは,次のような形の句でも呼出される ⇒ 次を走らす`~fetch~taskを~queueする$( %~taskの行先 ) ⇒ ( %~algo の内容)
【 この形の句は、和訳に特有であり,簡潔に表記するために導入している。 (それに伴い,引数の順序も入れ替えている。) 】
`整数を直列化する@ ときは、所与の整数を最短の 10 進数で表現する文字列を返す。 ◎ To serialize an integer, represent it as a string of the shortest possible decimal number.
これは、 `INFRA$r にて もっと記述的な~algoに置換されることになる。 infra/201 を見よ。 ◎ This will be replaced by a more descriptive algorithm in Infra. See infra/201.
2.1. ~URL
次に挙げる`~scheme$urlが `局所~scheme@ である ⇒# `about^l, `blob^l, `data^l ◎ A local scheme is a scheme that is "about", "blob", or "data".
`~URL$が `局所的@ であるとは、その`~scheme$urlが`局所~scheme$であることを意味する。 ◎ A URL is local if its scheme is a local scheme.
注記: この定義は `Referrer Policy^cite `REFERRER$r からも利用される。 ◎ This definition is also used by Referrer Policy. [REFERRER]
次に挙げる`~scheme$urlが `~HTTP_S~scheme@ である ⇒# `http^l, `https^l ◎ An HTTP(S) scheme is a scheme that is "http" or "https".
次に挙げる`~scheme$urlが `~fetch~scheme@ である ⇒# `about^l, `blob^l, `data^l, `file^l, `~HTTP_S~scheme$ ◎ A fetch scheme is a scheme that is "about", "blob", "data", "file", or an HTTP(S) scheme.
注記: `~HTTP_S~scheme$, `~fetch~scheme$ は~HTMLからも利用される。 `HTML$r ◎ HTTP(S) scheme and fetch scheme are also used by HTML. [HTML]
2.2. ~HTTP
`~fetching$は,単なる~HTTPを超えるものを包摂するが、~HTTPからいくつかの概念を流用し,それらを他の手段(例えば `data^c ~URL)を通して得された資源に対してもあてはめる。 ◎ While fetching encompasses more than just HTTP, it borrows a number of concepts from HTTP and applies these to resources obtained via other means (e.g., data URLs).
`~HTTP~tab-or-space@ は[ `0009^U `TAB^cn / `0020^U `SPACE^cn ]である。 ◎ An HTTP tab or space is U+0009 TAB or U+0020 SPACE.
`~HTTP空白@ は[ `000A^U `LF^cn / `000D^U `CR^cn / `~HTTP~tab-or-space$ ]である。 ◎ HTTP whitespace is U+000A LF, U+000D CR, or an HTTP tab or space.
注記: `~HTTP空白$が有用になるのは、~HTTP~headerの文脈の外側で再利用される特定の構成子(例:`~MIME型$)に限られる。 ~HTTP~header値~用には,`~HTTP~tab-or-space$の利用が選好され、その文脈の外側では,`~ASCII空白$が選好される。 `~ASCII空白$と違って、これは `000C^U `FF^cn を含まない。 ◎ HTTP whitespace is only useful for specific constructs that are reused outside the context of HTTP headers (e.g., MIME types). For HTTP header values, using HTTP tab or space is preferred, and outside that context ASCII whitespace is preferred. Unlike ASCII whitespace this excludes U+000C FF.
`~HTTP改行~byte@ は、[ `0A^X `LF^smb / `0D^X `CR^smb ]である。 ◎ An HTTP newline byte is 0x0A (LF) or 0x0D (CR).
`~HTTP~tab-or-space~byte@ は、[ `09^X `HT^smb / `20^X `SP^smb ]である。 ◎ An HTTP tab or space byte is 0x09 (HT) or 0x20 (SP).
`~HTTP空白~byte@ は、[ `~HTTP改行~byte$ / `~HTTP~tab-or-space~byte$ ]である。 ◎ An HTTP whitespace byte is an HTTP newline byte or HTTP tab or space byte.
`~HTTP引用符付き文字列を収集する@ ときは、所与の ( `文字列$ %入力, `位置~変数$ %位置, %値を抽出する~flag ~IN { `値を抽出する^i, ε }(省略時は ε ) ) に対し,次を走らす: ◎ To collect an HTTP quoted string from a string input, given a position variable position and optionally an extract-value flag, run these steps:
- %開始-位置 ~LET %位置 ◎ Let positionStart be position.
- %値 ~LET 空~文字列 ◎ Let value be the empty string.
- ~Assert: %位置↗ ~EQ `0022^U `"^smb ◎ Assert: the code point at position within input is U+0022 (").
- %位置 ~INCBY 1 ◎ Advance position by 1.
-
~WHILE 無条件: ◎ While true:
- %値 に次の結果を付加する ⇒ %入力 内の %位置 から { `0022^U `"^smb, `005C^U `\^smb } 以外の`符号位置~並びを収集する$ ◎ Append the result of collecting a sequence of code points that are not U+0022 (") or U+005C (\) from input, given position, to value.
- ~Assert: %位置↗ ~IN { ε, `0022^U `"^smb, `005C^U `\^smb } ◎ If position is past the end of input, then break.
-
~IF[ %位置↗ ~EQ `005C^U `\^smb ]:
- %位置 ~INCBY 1
- ~IF[ %位置↗ ~NEQ ε ] ⇒# %値 に %位置↗ を付加する; %位置 ~INCBY 1; ~CONTINUE
- %値 に `005C^U `\^smb を付加する
- ~IF[ %位置↗ ~NEQ ε ] ⇒ %位置 ~INCBY 1 ◎ ↑↓
- ~BREAK ◎ Otherwise: • Assert: quoteOrBackslash is U+0022 ("). • Break.
- ~IF[ %値を抽出する~flag ~NEQ ε ] ⇒ ~RET %値 ◎ If the extract-value flag is set, then return value.
- ~RET %入力 内の[ %開始-位置 から ( %位置 ~MINUS 1 ) まで ]にある`符号位置$並び 【!inclusive は先頭のみ(例:この時点で %位置↗ は ε かもしれない)】 ◎ Return the code points from positionStart to position, inclusive, within input.
入力 | 出力 | 出力( `値を抽出する^i ) | 最終- %位置 値† |
---|---|---|---|
`"\^l | `"\^l | `\^l | 2 |
`"Hello" World^l | `"Hello"^l | `Hello^l | 7 |
`"Hello \\ World\""^l | `"Hello \\ World\""^l | `Hello \ World"^l | 18 |
† この例では、`位置~変数$ %位置 は,常に 0 から開始するとする。
◎ Input Output Output with the extract-value flag set Final position variable value ""\" ""\" "\" 2 ""Hello" World" ""Hello"" "Hello" 7 ""Hello \\ World\""" ""Hello \\ World\""" "Hello \ World"" 18 ◎ The position variable always starts at 0 in these examples.2.2.1. ~method
`~method@ は、 `method$p ~token生成規則に合致する~byte列である。 【~HTTPにおける`要請~method$に対応する。】 ◎ A method is a byte sequence that matches the method token production.
`~CORS安全とされる~method@ は、次のいずれかの`~method$である ⇒# `GET$hm, `HEAD$hm, `POST$hm ◎ A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`.
`禁止~method@ は、次のいずれかに`~byte大小無視$で合致する`~method$である `HTTPVERBSEC1$r `HTTPVERBSEC2$r `HTTPVERBSEC3$r ⇒# `CONNECT$hm, `TRACE$hm, `TRACK$hm ◎ A forbidden method is a method that is a byte-case-insensitive match for `CONNECT`, `TRACE`, or `TRACK`. [HTTPVERBSEC1], [HTTPVERBSEC2], [HTTPVERBSEC3]
`~methodを正規化する@ ときは、所与の ( `~method$ %M ) に対し,[ %M が次のいずれかに`~byte大小無視$で合致するならば `~byte大文字~化する$( %M ) / ~ELSE_ %M ]を返す ⇒# `DELETE$hm, `GET$hm, `HEAD$hm, `OPTIONS$hm, `POST$hm, `PUT$hm ◎ To normalize a method, if it is a byte-case-insensitive match for `DELETE`, `GET`, `HEAD`, `OPTIONS`, `POST`, or `PUT`, byte-uppercase it.
注記: `~method$は実際には “文字大小区別” であるが、[ 後方-互換性, 各種~API間の一貫性 ]を得るため,`正規化-$mdが行われる。 ◎ Normalization is done for backwards compatibility and consistency across APIs as methods are actually "case-sensitive".
`patch^hm を利用した結果は、ほぼ間違いなく `405 Method Not Allowed^bl になるであろう。 `PATCH^hm の方がずっと成功する見込みが高い。 ◎ Using `patch` is highly likely to result in a `405 Method Not Allowed`. `PATCH` is much more likely to succeed.
注記: `~method$に制約はない。 `CHICKEN^hm ( `CHECKIN^hm の誤記ではない)でも,まったく受容-可能である。 `正規化-$mdされるものを除き、文字大小~法についての制約もない。 一貫性を得るため,大文字が奨励されるが、 `Egg^hm や `eGg^hm でもかまわない。 ◎ There are no restrictions on methods. `CHICKEN` is perfectly acceptable (and not a misspelling of `CHECKIN`). Other than those that are normalized there are no casing restrictions either. `Egg` or `eGg` would be fine, though uppercase is encouraged for consistency.
2.2.2. ~header
`~header~list@ は、 0 個以上の`~header$からなる`~list$であり、初期~時は空~listとする。 ◎ A header list is a list of zero or more headers. It is initially the empty list.
【 ~HTTPにおける~messageの`~header節$に対応する(現時点では、この仕様には,`~trailer$は現れない)。 】
注記: `~header~list$は、本質的には特化された ~multimapである — すなわち,何個かの ( ~key: 値 ) ~pairからなる有順序~listであって,~keyが重複し得るものである。 ◎ A header list is essentially a specialized multimap: an ordered list of key-value pairs with potentially duplicate keys.
`~header~list$ %~list から `有構造~field値を取得する@ ときは、所与の ( %名前, %型 ) に対し,次の手続きを走らす: ◎ To get a structured field value given a name and a type from a header list list, run these steps:
- ~Assert: %型 ~IN { `辞書^i, `~list^i, `~item^i } 【!"dictionary", "list", or "item"】 ◎ Assert: type is one of "dictionary", "list", or "item".
- %値 ~LET `~header~listから値を取得する$( %~list, %名前 ) ◎ Let value be the result of getting name from list.
- ~IF[ %値 ~EQ ~NULL ] ⇒ ~RET ~NULL ◎ If value is null, then return null.
- %結果 ~LET `有構造~fieldを構文解析する$( %値, %型 ) ◎ Let result be the result of parsing structured fields with input_string set to value and header_type set to type.
- ~IF[ 前~段の構文解析に失敗した ] ⇒ ~RET ~NULL ◎ If parsing failed, then return null.
- ~RET %結果 ◎ Return result.
注記: `有構造~field値を取得する$は、[ `~header$が無いこと, その`値$hdを`有構造~field値$として構文解析するのに失敗したこと ]を意図的に判別しない。 これは、~web~platformにわたる一様な処理を確保する。 ◎ Get a structured field value intentionally does not distinguish between a header not being present and its value failing to parse as a structured field value. This ensures uniform processing across the web platform.
`~header~list$ %~list 内で `有構造~field値を設定する@ ときは、所与の~pair ( `名前$hd %名前 / `有構造~field値$ %有構造~値 ) に対し,次を走らす: ◎ To set a structured field value name/structured field value name/structuredValue pair in a header list list, run these steps:
- %直列化した値 ~LET `有構造~fieldを直列化する$( %有構造~値 ) ◎ Let serializedValue be the result of executing the serializing structured fields algorithm on structuredValue.
- %~list 内で`~headerを設定する$( %名前 / %直列化した値 ) ◎ Set name/serializedValue in list.
注記: `有構造~field値$は、興味を引く効率的な仕方で[ ~HTTPが(最終的に)直列化できる~obj ]として定義される。 ~fetchは,当面の間は、`~header$の`値$hdを`~byte列$に限り~supportする。 すなわち、これらの~objを`~header~list$内に設定するためには,直列化を介する他になく、`~header~list$から得するためには,構文解析する他にない。 将来には、それらが~objである事は,端点間で保全されるであろう。 `HEADER-STRUCTURE$r ◎ Structured field values are defined as objects which HTTP can (eventually) serialize in interesting and efficient ways. For the moment, Fetch only supports header values as byte sequences, which means that these objects can be set in header lists only via serialization, and they can be obtained from header lists only by parsing. In the future the fact that they are objects might be preserved end-to-end. [HEADER-STRUCTURE]
所与の`名前$hd(または`~byte列$) %名前 を `名前に持つ~header@ とは、`~header$であって,その`名前$hdが[ `~byte大小無視$で %名前 に合致する ]ものを指す。
【 言い換えれば、`~header$の`名前$hdは,常に`~byte大小無視$で比較される — 元々の~HTTP~protocolが,~header名の文字大小を区別しないので。 】【 この用語は、他所を簡便に記すために,この訳にて導入している。 】
[ そのような`~header$を所与の`~list$ %~list が`包含して$いる ]という条件は、単に, “%~list 内に %名前 を`名前に持つ~header$は在る” と記される(その否定は “無い” と記される)。
【 この条件は、原文では “`~header~list$は %名前 を `包含する@hd” という句として定義されているが、この訳(および,この仕様を参照している和訳)では,この用語 “包含する” は利用せず,もっぱら`名前に持つ~header$を用いて等価に記すことにする。 】
◎ A header list list contains a name name if list contains a header whose name is a byte-case-insensitive match for name.`~header~listから値を取得する@ ときは,所与の ( `~header~list$ %~list, `名前$hd %名前 ) に対し,次を走らす: ◎ To get a name name from a header list list, run these steps:
- ~IF[ %~list 内に %名前 を`名前に持つ~header$は無い ] ⇒ ~RET ~NULL ◎ If list does not contain name, then return null.
- ~RET %~list 内の[ %名前 を`名前に持つ~header$ ]すべての`値$hdを互いに[ `2C^X `20^X ]並びで区切って順に連結した結果 ◎ Return the values of all headers in list whose name is a byte-case-insensitive match for name, separated from each other by 0x2C 0x20, in order.
`~header~listから値を取得して復号して分割する@ ときは、所与の ( `~header~list$ %~list, `名前$hd %名前 ) に対し,次を走らす: ◎ To get, decode, and split a name name from header list list, run these steps:
- %初期~値 ~LET `~header~listから値を取得する$( %~list, %名前 ) ◎ Let initialValue be the result of getting name from list.
- ~IF[ %初期~値 ~EQ ~NULL ] ⇒ ~RET ~NULL ◎ If initialValue is null, then return null.
- %入力 ~LET `同型に復号する$( %初期~値 ) ◎ Let input be the result of isomorphic decoding initialValue.
- %位置 ~LET %入力 内の先頭を指している`位置~変数$ ◎ Let position be a position variable for input, initially pointing at the start of input.
- %値~list ~LET 空`~list$ ◎ Let values be a list of strings, initially empty.
- %値 ~LET 空~文字列 ◎ Let value be the empty string.
-
~WHILE [ %位置↗ ~NEQ ε ]: ◎ While position is not past the end of input:
-
%値 に次の結果を付加する ⇒ %入力 内の %位置 から { `0022^U `"^smb, `002C^U `,^smb } 以外の`符号位置~並びを収集する$ ◎ Append the result of collecting a sequence of code points that are not U+0022 (") or U+002C (,) from input, given position, to value.
注記: 結果は空~文字列にもなり得る。 ◎ The result might be the empty string.
-
~IF[ %位置↗ ~NEQ ε ]: ◎ If position is not past the end of input, then:
-
~IF[ %位置↗ ~EQ `0022^U `"^smb ]: ◎ If the code point at position within input is U+0022 ("), then:
- %値 に次の結果を付加する ⇒ `~HTTP引用符付き文字列を収集する$( %入力, %位置 ) ◎ Append the result of collecting an HTTP quoted string from input, given position, to value.
- ~IF[ %位置↗ ~NEQ ε ] ⇒ ~CONTINUE ◎ If position is not past the end of input, then continue.
-
~ELSE: ◎ Otherwise:
- ~Assert: %位置↗ ~EQ `002C^U `,^smb ◎ Assert: the code point at position within input is U+002C (,).
- %位置 ~INCBY 1 ◎ Advance position by 1.
-
- %値 から[ 頭部, 尾部 ]を成すすべての`~HTTP~tab-or-space$を除去する ◎ Remove all HTTP tab or space from the start and end of value.
- %値~list に %値 を`付加する$ ◎ Append value to values.
- %値 ~SET 空~文字列 ◎ Set value to the empty string.
-
- ~RET %値~list ◎ Return values.
`~header~listから値を取得して復号して分割する$が、その引数 %名前 に `A^bl が与えられた下で,実施において どう機能するかを次に示す: ◎ This is how get, decode, and split functions in practice with `A` as the name argument:
(~network上の)~header列 ◎ Headers (as on the network) | 出力 |
---|---|
A: nosniff, | « `nosniff^l, "" » |
A: nosniff B: sniff A: | |
A: text/html;", x/x | « `text/html;", x/x^l » |
A: text/html;" A: x/x | |
A: x/x;test="hi",y/y | « `x/x;test="hi"^l, `y/y^l » |
A: x/x;test="hi" C: **bingo** A: y/y | |
A: x / x,,,1 | « `x / x^l, "", "", `1^l » |
A: x / x A: , A: 1 | |
A: "1,2", 3 | « `"1,2"^l, `3^l » |
A: "1,2" D: 4 A: 3 |
`~header~list$ %~list に `~headerを付加する@ ときは、所与の~pair ( `名前$hd %名前 / `値$hd %値 ) に対し,次を走らす: ◎ To append a name/value name/value pair to a header list list, run these steps:
-
~IF[ %~list 内に[ %名前 を`名前に持つ~header$ ]は在る ] ⇒ %名前 ~SET そのような`~header$のうち最初のものの`名前$hd ◎ If list contains name, then set name to the first such header’s name.
注記: これは、 %~list 内に該当する`~header$がすでにあれば,その`名前$hdの文字大小を再利用させる。 該当する~headerが複数あれば、それらすべての名前は同じ文字大小にされることになる。 ◎ This reuses the casing of the name of the header already in list, if any. If there are multiple matched headers their names will all be identical.
- %~list に `新たな~header$( %名前 / %値 ) を`付加する$ ◎ Append a new header whose name is name and value is value to list.
`~header~list$ %~list から `~headerを削除する@ ときは、所与の ( `名前$hd %名前 ) に対し,次を走らす ⇒ %~list から[ %名前 を`名前に持つ~header$ ]をすべて`除去する$ ◎ To delete a name name from a header list list, remove all headers whose name is a byte-case-insensitive match for name from list.
`~header~list$ %~list 内で `~headerを設定する@ ときは、所与の~pair ( `名前$hd %名前 / `値$hd %値 ) に対し,次を走らす: ◎ To set a name/value name/value pair in a header list list, run these steps:
- ~IF[ %~list 内に[ %名前 を`名前に持つ~header$ ]は在る ] ⇒ そのような`~header$のうち ⇒# 最初のものに対しては,その`値$hd ~SET %値; 他のものは, %~list から`除去する$ ◎ If list contains name, then set the value of the first such header to value and remove the others.
- ~ELSE ⇒ %~list に `新たな~header$( %名前 / %値 ) を`付加する$ ◎ Otherwise, append a new header whose name is name and value is value to list.
`~header~list$ %~list 内で `~headerを結合する@ ときは、所与の~pair ( `名前$hd %名前 / `値$hd %値 ) に対し,次を走らす: ◎ To combine a name/value name/value pair in a header list list, run these steps:
- ~IF[ %~list 内に[ %名前 を`名前に持つ~header$ ]は在る ] ⇒ そのような`~header$のうち,最初のものに対し ⇒ その`値$hdの末尾に[ `2C^X, `20^X, %値 ]を順に付加する ◎ If list contains name, then set the value of the first such header to its value, followed by 0x2C 0x20, followed by value.
- ~ELSE ⇒ %~list に `新たな~header$( %名前 / %値 ) を`付加する$ ◎ Otherwise, append a new header whose name is name and value is value to list.
注記: `~headerを結合する$は、もっぱら[ `XMLHttpRequest$I / `~WebSocket~protocol~handshakeを確立する$ ]用に在る。 ◎ Combine is used by XMLHttpRequest and the WebSocket protocol handshake.
`~header名たちを小文字~化して~sortした集合に変換する@ ときは、所与の ( `名前$hdたちからなる`~list$ %~header名たち ) に対し,次を走らす: ◎ To convert header names to a sorted-lowercase set, given a list of names headerNames, run these steps:
- %~header名~集合 ~LET 新たな`有順序~集合$ ◎ Let headerNamesSet be a new ordered set.
- %~header名たち を成す ~EACH( %名前 ) に対し ⇒ %~header名~集合 に次の結果を`付加する$set ⇒ `~byte小文字~化する$( %名前 ) ◎ For each name of headerNames, append the result of byte-lowercasing name to headerNamesSet.
- ~RET `~listを昇順に~sortする$( %~header名~集合, `未満の~byte列$ ) ◎ Return the result of sorting headerNamesSet in ascending order with byte less than.
`~header~listを~sortして結合する@ ときは、所与の ( `~header~list$ %~list ) に対し,次を走らす: ◎ To sort and combine a header list list, run these steps:
- %結果~list ~LET 空`~list$ ◎ Let headers be an empty list of name-value pairs with the key being the name and value the value.
- %名前たち ~LET `~header名たちを小文字~化して~sortした集合に変換する$( %~list 内のすべての`~header$の`名前$hd ) ◎ Let names be the result of convert header names to a sorted-lowercase set with all the names of the headers in list.
-
%名前たち 内の ~EACH( %名前 ) に対し: ◎ For each name in names:
- %値 ~LET `~header~listから値を取得する$( %~list, %名前 ) ◎ Let value be the result of getting name from list.
- ~Assert: %値 ~NEQ ~NULL ◎ Assert: value is not null.
- %結果~list に 次のようにされた~pairを`付加する$ ⇒ ( ~key, 値 ) ~SET ( %名前, %値 ) ◎ Append name-value to headers.
- ~RET %結果~list ◎ Return headers.
`~header@ は、 `名前@hd および `値@hd からなる: ◎ A header consists of a name and value.
【 この仕様を通して、`~header$の[ `名前$hd, `値$hd ]が成す~pair, あるいは それを意図して与えられる~pairは、 “( %名前 / %値 )” のように,スラッシュで区切った上で丸括弧で括られて記される。 】【 [ `~header$/`名前$hd/`値$hd ]は、~HTTPにおける[ `~field行l$/`~field名$/`~field行l値$ ]に対応する。 】
-
`名前$hdは、 `field-name$p ~token生成規則に合致する`~byte列$である。
【 ある`名前$hdに`~byte大小無視$で合致する どの`~byte列$も、`名前$hdになる。 】
◎ A name is a byte sequence that matches the field-name token production. -
`値$hdは、次の両~条件に合致する`~byte列$である: ◎ A value is a byte sequence that matches the following conditions:
- [ 頭部, 尾部 ]を成す`~HTTP~tab-or-space~byte$は無い。 ◎ Has no leading or trailing HTTP tab or space bytes.
- `00^X `NUL^smb, `~HTTP改行~byte$は包含しない。 ◎ Contains no 0x00 (NUL) or HTTP newline bytes.
【 定義により、`値$hdは空~byte列もとり得ることになる。 】
注記: `値$hdの定義は、~HTTP~token生成規則を通しては定義されていない — それは壊れている 。 ◎ The definition of value is not defined in terms of an HTTP token production as it is broken.
`新たな~header@( %名前 / %値 ) という表記は、 ( `名前$hd / `値$hd ) ~SET ( %名前 / %値 ) にされた,新たな`~header$を意味する。 【この表記は、この訳による追加。】
`値を正規化する@ ときは、所与の ( `~byte列$ %値 ) に対し, %値 から[ 頭部, 尾部 ]を成す`~HTTP空白~byte$並びを除去した結果を返す。 ◎ To normalize a potentialValue, remove any leading and trailing HTTP whitespace bytes from potentialValue.
所与の`~header$ %~header が `~CORS安全とされる要請~header@ かどうか決定するときは、次を走らす: ◎ To determine whether a header header is a CORS-safelisted request-header, run these steps:
- %値 ~LET %~header の`値$hd ◎ Let value be header’s value.
-
~IF[[ %~header は、次の表の 1 列目に挙げるどれを`名前に持つ~header$か ]に応じて,同じ行の 2 列目に与える条件が満たされる ] ⇒ ~RET ~F ◎ Byte-lowercase header’s name and switch on the result:
~header名 条件 `Accept$h %値 を成す ある~byteは、`~CORS非安全な要請~header~byte$である ◎ If value contains a CORS-unsafe request-header byte, then return false. `Accept-Language$h, `Content-Language$h %値 を成す ある~byteは、次に挙げる どれでもない ⇒# `20^X `SP^smb, `2A^X `*^smb, `2C^X `,^smb, `2D^X `-^smb, `2E^X `.^smb, `30^X `0^smb 〜 `39^X `9^smb, `3B^X `;^smb, `3D^X `=^smb, `41^X `A^smb 〜 `5A^X `Z^smb, `61^X `a^smb 〜 `7A^X `z^smb, ◎ If value contains a byte that is not in the range 0x30 (0) to 0x39 (9), inclusive, is not in the range 0x41 (A) to 0x5A (Z), inclusive, is not in the range 0x61 (a) to 0x7A (z), inclusive, and is not 0x20 (SP), 0x2A (*), 0x2C (,), 0x2D (-), 0x2E (.), 0x3B (;), or 0x3D (=), then return false. `Content-Type$h 次のいずれかが満たされる:
- %値 を成す ある~byteは、`~CORS非安全な要請~header~byte$である
- `~MIME型を構文解析する$( %値 ) の結果は `失敗^i, または 次を満たす ⇒ 結果の`~essence$ ~NIN { `application/x-www-form-urlencoded^l, `multipart/form-data^l, `text/plain^l }
これは、`~header~listから~MIME型を抽出する$ を意図的に利用しない。 その~algoは~~寛容にされており、~serverが実装することは期待されていないので。 ◎ This intentionally does not use extract a MIME type as that algorithm is rather forgiving and servers are not expected to implement it.
`~header~listから~MIME型を抽出する$ が利用された場合、次の要請からは~CORS予行~要請は生じなくなり,~server上の素朴な構文解析器は要請~本体を~JSONとして扱うかもしれない: ◎ If extract a MIME type were used the following request would not result in a CORS preflight and a naïve parser on the server might treat the request body as JSON:
fetch("https://victim.example/naïve-endpoint", { method: "POST", headers: [ ["Content-Type", "application/json"], ["Content-Type", "text/plain"] ], credentials: "include", body: JSON.stringify(exerciseForTheReader) });
その他 ◎ Otherwise 無条件 ◎ Return false. - ~IF[ %値 の`長さ$ ~GT 128 ] ⇒ ~RET ~F ◎ If value’s length is greater than 128, then return false.
- ~RET ~T ◎ Return true.
注記: ~CORS安全とされる `Content-Type$h ~headerには,制限付きな例外がある — § ~CORS~protocol例外 を見よ。 ◎ There are limited exceptions to the `Content-Type` header safelist, as documented in CORS protocol exceptions.
次に挙げる~byteは、 `~CORS非安全な要請~header~byte@ とされる ⇒# `0^X 〜 `08^X, `0A^X 〜 `1F^X, `22^X `"^smb, `28^X `(^smb, `29^X `)^smb, `3A^X `:^smb, `3C^X `<^smb, `3E^X `>^smb, `3F^X `?^smb, `40^X `@^smb, `5B^X `[^smb, `5C^X `\^smb, `5D^X `]^smb, `7B^X `{^smb, `7D^X `}^smb, `7F^X `DEL^smb ◎ A CORS-unsafe request-header byte is a byte byte for which one of the following is true: • byte is less than 0x20 and is not 0x09 HT • byte is 0x22 ("), 0x28 (left parenthesis), 0x29 (right parenthesis), 0x3A (:), 0x3C (<), 0x3E (>), 0x3F (?), 0x40 (@), 0x5B ([), 0x5C (\), 0x5D (]), 0x7B ({), 0x7D (}), or 0x7F DEL.
`~CORS非安全な要請~header名たち@ は、所与の ( `~header~list$ %~headerたち ) に対し,次に従って決定される: ◎ The CORS-unsafe request-header names, given a header list headers, are determined as follows:
- %非安全な名前たち ~LET 新たな`~list$ ◎ Let unsafeNames be a new list.
- %非安全になり得る名前たち ~LET 新たな`~list$ ◎ Let potentiallyUnsafeNames be a new list.
- %安全な値の合計~size ~LET 0 ◎ Let safelistValueSize be 0.
-
%~headerたち を成す ~EACH( %~header ) に対し: ◎ For each header of headers:
- ~IF[ %~header は`~CORS安全とされる要請~header$でない ] ⇒ %非安全な名前たち に %~header の`名前$hdを`付加する$ ◎ If header is not a CORS-safelisted request-header, then append header’s name to unsafeNames.
- ~ELSE ⇒# %非安全になり得る名前たち に %~header の`名前$hdを`付加する$; %安全な値の合計~size ~INCBY %~header の`値$hdの`長さ$ ◎ Otherwise, append header’s name to potentiallyUnsafeNames and increase safelistValueSize by header’s value’s length.
- ~IF[ %安全な値の合計~size ~GT 1024 ] ⇒ %非安全になり得る名前たち を成す ~EACH( %名前 ) に対し ⇒ %非安全な名前たち に %名前 を`付加する$ ◎ If safelistValueSize is greater than 1024, then for each name of potentiallyUnsafeNames, append name to unsafeNames.
- ~RET `~header名たちを小文字~化して~sortした集合に変換する$( %非安全な名前たち ) ◎ Return the result of convert header names to a sorted-lowercase set with unsafeNames.
`~CORS非~wildcard要請~header名@ は、[ 次に挙げるいずれかの`名前$hdに`~byte大小無視$で合致する`名前$hd ]である ⇒# `Authorization$h ◎ A CORS non-wildcard request-header name is a byte-case-insensitive match for `Authorization`.
`特権的~CORSなし要請~header名@ は、[ 次に挙げるいずれかの`名前$hdに`~byte大小無視$で合致する`名前$hd ]である ⇒# `Range$h ◎ A privileged no-CORS request-header name is a header name that is a byte-case-insensitive match for one of • `Range`
注記: これらは、特権的~APIにより設定され得る~headerであり,それを結付けている要請~objが複製される場合には 保全されるが、その要請が特権的でない~APIにより改変された場合には 除去されることになる。 ◎ These are headers that can be set by privileged APIs, and will be preserved if their associated request object is copied, but will be removed if the request is modified by unprivilaged APIs.
`Range$h ~headerは,[ ~downloadする / ~mediaを~fetchする ]ときに共通して利用されるが、どちらも,どう利用するかまだ指定していない。 html/2914 がこれを解くことを目指す。 ◎ `Range` headers are commonly used by downloads and media fetches, although neither of these currently specify how. html/2914 aims to solve this.
特定0の要請に`範囲~headerを追加する$ために,~helperが供される。【?】 ◎ A helper is provided to add a range header to a particular request.
所与の`~CORSに公開される~header名~list$rs %~list 内の `~CORS安全とされる応答~header名@ とは、次をいずれも満たす`名前$hdである:
- `禁止~応答~header名$でない
- [ %~list に挙げられた値, 次に挙げる`名前$hd ]のいずれかに`~byte大小無視$で合致する ⇒# `Cache-Control$h, `Content-Language$h, `Content-Length$h, `Content-Type$h, `Expires$h, `Last-Modified$h, `Pragma$h
`~CORSなしで安全とされる要請~header名@ とは、次に挙げるいずれかに`~byte大小無視$で合致する`名前$hdである ⇒# `Accept$h, `Accept-Language$h, `Content-Language$h, `Content-Type$h ◎ A no-CORS-safelisted request-header name is a header name that is a byte-case-insensitive match for one of • `Accept` • `Accept-Language` • `Content-Language` • `Content-Type`
`~CORSなしで安全とされる要請~header@ とは、次をいずれも満たす`~header$である: ◎ To determine whether a header header is a no-CORS-safelisted request-header, run these steps:
- `~CORSなしで安全とされる要請~header名$を`名前に持つ~header$である ◎ If header’s name is not a no-CORS-safelisted request-header name, then return false.
- `~CORS安全とされる要請~header$である ◎ Return whether header is a CORS-safelisted request-header.
`禁止~header名@ とは、次のいずれかに該当する`名前$hdである: ◎ A forbidden header name is a header name that is a byte-case-insensitive match for one of
-
次に挙げるいずれかに`~byte大小無視$で合致するもの ⇒# `Accept-Charset$h, `Accept-Encoding$h, `Access-Control-Request-Headers$h, `Access-Control-Request-Method$h, `Connection$h, `Content-Length$h, `Cookie$h, `Cookie2^h, `Date$h, `DNT^h 【Do Not Track】, `Expect$h, `Host$h, `Keep-Alive$h, `Origin$h, `Referer$h, `TE$h, `Trailer$h, `Transfer-Encoding$h, `Upgrade$h, `Via$h
- 頭部が[ `Proxy-^h, `Sec-^h ]のいずれかに`~byte大小無視$で合致するもの(合致する頭部が全体であるものも含む)。 ◎ or a header name that starts with a byte-case-insensitive match for `Proxy-` or `Sec-` (including being a byte-case-insensitive match for just `Proxy-` or `Sec-`).
注記: これらは、全部的に~UAの制御~下に留め置くため,禁止される。 `Sec-^h で始まる`名前$hdは、~APIから安全に[ `XMLHttpRequest$I などの,開発者による制御が許容される`~header$が含まれた`~fetch$ ]を行えるような,新種の`~header$を創出できるようにするため、予約されている。 `XHR$r ◎ These are forbidden so the user agent remains in full control over them. Names starting with `Sec-` are reserved to allow new headers to be minted that are safe from APIs using fetch that allow control over headers by developers, such as XMLHttpRequest. [XHR]
`禁止~応答~header名@ とは、次のいずれかに`~byte大小無視$で合致する`名前$hdである ⇒# `Set-Cookie$h, `Set-Cookie2^h ◎ A forbidden response-header name is a header name that is a byte-case-insensitive match for one of: • `Set-Cookie` • `Set-Cookie2`
`要請~本体~header名@ とは、次のいずれかに`~byte大小無視$で合致する`名前$hdである ⇒# `Content-Encoding$h `Content-Language$h `Content-Location$h `Content-Type$h ◎ A request-body-header name is a header name that is a byte-case-insensitive match for one of: • `Content-Encoding` • `Content-Language` • `Content-Location` • `Content-Type`
`~headerから値を抽出する@ ときは、所与の ( `~header$ %~header ) に対し,次を走らす: ◎ To extract header values given a header header, run these steps:
- %~header の`値$hdを[ %~header の`名前$hd用の`~ABNF$ ]に従って構文解析する 【 ~HTTPの § ~field行lの構文解析】 ◎ If parsing header’s value, per the ABNF for header’s name, fails, then return failure.
- ~RET[ 前~段に失敗したならば `失敗^i / ~ELSE_ 前~段による結果を成す 1 個以上の`値$hd ] ◎ Return one or more values resulting from parsing header’s value, per the ABNF for header’s name.
`~header~listから値を抽出する@ ときは、所与の ( `~header~list$ %~header~list, `名前$hd %名前 ) に対し,次を走らす: ◎ To extract header list values given a name name and a header list list, run these steps:
- %~list ~LET %~header~list 内の[ %名前 を`名前に持つ~header$ ]すべてからなる~list ◎ ↓
- ~IF[ %~list は空である ] ⇒ ~RET ~NULL ◎ If list does not contain name, then return null.
-
~IF[[ %名前 用の`~ABNF$ ]にて許容されている`~header$の個数 は 1 個† ]~AND[ %~list 内に複数個の`~header$がある ] ⇒ ~RET `失敗^i ◎ If the ABNF for name allows a single header and list contains more than one, then return failure.
注記: 異なる~errorの取扱いが必要な場合††、事前に~~目的の`~header$を抽出すること。 ◎ If different error handling is needed, extract the desired header first.
【† すなわち、 %名前 は`単数~field$の名前を与えている。 】【†† ~HTTPの § ~fieldの順序と結合 の注記( `Set-Cookie$h )に加え, § `Content-Length$h の最後の方の記述なども該当するように見受けられる。 】
- %値~list ~LET 空`~list$ ◎ Let values be an empty list.
-
%~list 内の ~EACH( `~header$ %~header ) に対し: ◎ For each header header list contains whose name is name:
- %抽出- ~LET `~headerから値を抽出する$( %~header ) ◎ Let extract be the result of extracting header values from header.
- ~IF[ %抽出- ~EQ `失敗^i ] ⇒ ~RET `失敗^i ◎ If extract is failure, then return failure.
- %抽出- 内の ~EACH( `値$hd %値 ) に対し ⇒ %値~list に %値 を付加する ◎ Append each value in extract, in order, to values.
- ~RET %値~list† ◎ Return values.
【† `単数~field$である場合、この手続きを呼出している所では,結果の %値~list は暗黙的に その最初の値と同一視されている。 】
`既定の User-Agent 値@ とは、~UAが `User-Agent$h `~header$用に定義する`値$hdである。 ◎ A default `User-Agent` value is a user-agent-defined value for the `User-Agent` header.
2.2.3. 状態s
`状態s@ は、範囲 { 0 〜 999 } に入る整数である。 【~HTTPにおける`応答~状態s~code$に対応する。】 ◎ A status is an integer in the range 0 to 999, inclusive.
課題 #1156 にて,[ HTTP/1 の `status-code$p から この概念への対応付け ]における様々な際どい事例が作業されている。 ◎ Various edge cases in mapping HTTP/1’s status-code to this concept are worked on in issue #1156.
次に挙げる`状態s$は、 `~null本体~状態s@ であるとされる ⇒# `101$st, `204$st, `205$st, `304$st ◎ A null body status is a status that is 101, 204, 205, or 304.
次の範囲に入る`状態s$は、 `~ok状態s@ であるとされる ⇒ `200^st 〜 `299^st ◎ An ok status is a status in the range 200 to 299, inclusive.
次に挙げる`状態s$は、 `~redirect状態s@ であるとされる ⇒# `301$st, `302$st, `303$st, `307$st, `308$st ◎ A redirect status is a status that is 301, 302, 303, 307, or 308.
2.2.4. 本体
`本体@ ( `body^en )は、次に挙げるものからなる: ◎ A body consists of:
- `~stream@bd
- `ReadableStream$I ~obj。 ◎ A stream (a ReadableStream object).
- `総~byte数@bd
- 整数 — 初期~時は 0 。 ◎ A total bytes (an integer), initially 0.
- `~source@bd
- 初期~時は ~NULL 。 ◎ A source, initially null.
【 本体は、~HTTPにおける~messageの`内容$に対応する。 】
`本体を~cloneする@ ときは、所与の ( `本体$ %本体 ) に対し,次を走らす: ◎ To clone a body body, run these steps:
- « %out1, %out2 » ~LET %本体 の`~stream$bdを`二叉化する$RS() ◎ Let « out1, out2 » be the result of teeing body’s stream.
- %本体 の`~stream$bd ~SET %out1 ◎ Set body’s stream to out1.
- ~RET 次のようにされた新たな`本体$ ⇒# `~stream$bd ~SET %out2; 他の~memberは %本体 から複製する ◎ Return a body whose stream is out2 and other members are copied from body.
`本体を増分的に読取る@ ときは、所与の ( %本体, %本体~chunkを処理する, %本体の終端を処理する, %本体~errorを処理する, %~taskの行先 ) に対し,次の手続きを走らす: ◎ To incrementally read a body body, given an algorithm processBodyChunk, an algorithm processEndOfBody, an algorithm processBodyError, and an optional null, parallel queue, or global object taskDestination (default null), run these steps.\
- ~Assert ⇒# %本体 は `本体$である/ %本体~chunkを処理する は `~byte列$を受容する~algoである/ %本体の終端を処理する は 引数をとらない~algoである/ %本体~errorを処理する は 例外を受容する~algoである/ %~taskの行先 (省略時は ~NULL )は [~NULL/`並列~queue$/`大域~obj$]である ◎ processBodyChunk must be an algorithm accepting a byte sequence. processEndOfBody must be an algorithm accepting no arguments. processBodyError must be an algorithm accepting an exception.
- ~IF[ %~taskの行先 ~EQ ~NULL ] ⇒ %~taskの行先 ~SET `新たな並列~queueを開始する$() ◎ If taskDestination is null, then set taskDestination to the result of starting a new parallel queue.
-
%読取器 ~LET %本体 の`~stream$bd用の`読取器を取得する$RS() ◎ Let reader be the result of getting a reader for body’s stream.
注記: この演算は例外を投出しない。 ◎ This operation will not throw an exception.
- `本体を増分的に読取る~loop$( 次に挙げる引数 ) ⇒# %読取器, %~taskの行先, %本体~chunkを処理する, %本体の終端を処理する, %本体~errorを処理する ◎ Perform the incrementally-read loop given reader, taskDestination, processBodyChunk, processEndOfBody, and processBodyError.
`本体を増分的に読取る~loop@ を遂行するときは、所与の ( %読取器, %~taskの行先, ~algo %本体~chunkを処理する, ~algo %本体の終端を処理する, ~algo %本体~errorを処理する ) に対し: ◎ To perform the incrementally-read loop, given a ReadableStreamDefaultReader object reader, parallel queue or global object taskDestination, algorithm processBodyChunk, algorithm processEndOfBody, and algorithm processBodyError:
- ~Assert ⇒# %読取器 は `ReadableStreamDefaultReader$I ~objである/ %~taskの行先 は [ `並列~queue$/`大域~obj$ ]である
-
%読取n要請 ~LET 新たな`読取n要請$ — その: ◎ Let readRequest be the following read request:
-
`~chunk手続き$rRは、所与の ( %~chunk ) に対し: ◎ chunk steps, given chunk • Let continueAlgorithm be null.
- ~IF[ %~chunk は `Uint8Array$I ~objでない ] ⇒ 次を走らす`~fetch~taskを~queueする$( %~taskの行先 ) ⇒ %本体~errorを処理する( `TypeError$E ) ◎ If chunk is not a Uint8Array object, then set continueAlgorithm to this step: run processBodyError given a TypeError.
-
~ELSE:
-
%~byte列 ~LET %~chunk の`複製を取得する$
注記: 実装には、[ アリな所では,この複製を避ける策を利用する ]ことが,強く奨励される。
-
次を走らす`~fetch~taskを~queueする$( %~taskの行先 ):
- %本体~chunkを処理する( %~byte列 )
- `本体を増分的に読取る~loop$( 次に挙げる引数 ) ⇒# %読取器, %~taskの行先, %本体~chunkを処理する, %本体の終端を処理する, %本体~errorを処理する
-
- `~close手続き$rRは: ⇒ `~fetch~taskを~queueする$( %~taskの行先, %本体の終端を処理する ) ◎ close steps • Queue a fetch task given processEndOfBody and taskDestination.
- `~error手続き$rRは、所与の ( %~error ) に対し ⇒ 次を走らす`~fetch~taskを~queueする$( %~taskの行先 ) ⇒ %本体~errorを処理する( %e ) ◎ error steps, given e • Queue a fetch task to run processBodyError given e, with taskDestination.
-
- %読取器 から`~chunkを読取る$RSR( %読取n要請 ) ◎ Read a chunk from reader given readRequest.
`本体を全部的に読取る@ ときは、所与の ( %本体, %本体を処理する, %本体~errorを処理する, %~taskの行先 ) に対し,次の手続きを走らす: ◎ To fully read a body body, given an algorithm processBody, an algorithm processBodyError, and an optional null, parallel queue, or global object taskDestination (default null), run these steps.\
- ~Assert ⇒# %本体 は `本体$である/ %本体を処理する は `~byte列$を受容する~algoである/ %本体~errorを処理する は 引数をとらない~algoである/ %~taskの行先 (省略時は ~NULL )は [~NULL/`並列~queue$/`大域~obj$]である ◎ processBody must be an algorithm accepting a byte sequence. processBodyError must be an algorithm accepting no arguments.
- ~IF[ %~taskの行先 ~EQ ~NULL ] ⇒ %~taskの行先 ~SET `新たな並列~queueを開始する$() ◎ If taskDestination is null, then set taskDestination to the result of starting a new parallel queue.
- %~promise ~LET `本体を~promiseとして全部的に読取る$( %本体 ) ◎ Let promise be the result of fully reading body as promise given body.
- %充足-時の手続き ~LET 所与の ( `~byte列$ %~byte列 ) に対し,次を走らす手続き ⇒ 次を走らす`~fetch~taskを~queueする$( %~taskの行先 ) ⇒ %本体を処理する( %~byte列 ) ◎ Let fulfilledSteps given a byte sequence bytes be to queue a fetch task to run processBody given bytes, with taskDestination.
- %却下-時の手続き ~LET 次を走らす手続き ⇒ 次を走らす`~fetch~taskを~queueする$( %~taskの行先 ) ⇒ %本体~errorを処理する() ◎ Let rejectedSteps be to queue a fetch task to run processBodyError, with taskDestination.
- %~promise に`反応する$( %充足-時の手続き, %却下-時の手続き ) ◎ React to promise with fulfilledSteps and rejectedSteps.
`本体を~promiseとして全部的に読取る@ ときは、所与の ( `本体$ %本体 ) に対し,次の手続きを走らす: ◎ To fully read body as promise, given a body body, run these steps:
- %読取器 ~LET %本体 の`~stream$bd用の`読取器を取得する$RS() ⇒ 例外が投出された場合は ⇒ ~RET その例外で`却下される~promise$ ◎ Let reader be the result of getting a reader for body’s stream. If that threw an exception, then return a promise rejected with that exception.
- ~RET %読取器 から`すべての~byteを読取る$RSR() ◎ Return the result of reading all bytes from reader.
`内容~符号法sを取扱う@ ときは、所与の ( 内容~符号法s† %符号法s, ~byte列 %~byte列 ) に対し,次を走らす 【† 複数の`内容~符号法$が重ねて適用されることもあり得る】 : ◎ To handle content codings given codings and bytes, run these steps:
- ~IF[ %符号法s 【内のいずれかの符号法】 は~supportされていない ] ⇒ ~RET %~byte列 ◎ If codings are not supported, then return bytes.
- ~RET [ 次の結果は~errorでないならば その結果 / ~ELSE_ `失敗^i ] ⇒ ~HTTPに従って, %~byte列 を %符号法s で復号する `HTTP$r `HTTP-SEMANTICS$r ◎ Return the result of decoding bytes with codings as explained in HTTP, if decoding does not result in an error, and failure otherwise. [HTTP] [HTTP-SEMANTICS]
2.2.5. 要請
`要請@ ( `request^en )は、`~fetch$への入力を与える。 ◎ The input to fetch is a request.
各 `要請$には、以下に挙げるものが結付けられる。 各~項には,それがとり得る値の種類を示す。 他が言明されない限り、[ 見出しの括弧内に与える値 ]を既定~値としてとるものとする: ◎ ↓
- `~method@rq( `GET$hm )
- `~method$。 ◎ A request has an associated method (a method). Unless stated otherwise it is `GET`.
- 注記: これは、`~HTTP~fetch$にて述べるように,~redirectの間に【 `POST$hm から】 `GET$hm に更新され得る。 【参考:状態s~code `3xx$st の注記】 ◎ This can be updated during redirects to `GET` as described in HTTP fetch.
- `~URL@rq
- `~URL$。 ◎ A request has an associated URL (a URL).
- 注記: 実装には、これが`要請$の`~URL~list$rq内の最初の`~URL$を指すようにすることが奨励される。 これはもっぱら、~Fetchの中へ~hookする他の標準の便利~用に,別個の~fieldとして供されている。 ◎ Implementations are encouraged to make this a pointer to the first URL in request’s URL list. It is provided as a distinct field solely for the convenience of other standards hooking into Fetch.
- 【 資源の~fetch先 — ~HTTPにおける`~target~URI$に対応する。 】
- `局所~URLのみ~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated local-URLs-only flag. Unless stated otherwise it is unset.
- `~header~list@rq( 空~list )
- `~header~list$。 ◎ A request has an associated header list (a header list). Unless stated otherwise it is empty.
- `非安全~要請~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated unsafe-request flag. Unless stated otherwise it is unset.
- 注記: `非安全~要請~flag$rqは、給された`~method$rqと`~header~list$rqに基づいて `~CORS予行~fetch$が行われるようにするために, `fetch()$m や `XMLHttpRequest$I などの~APIにより ~T にされる。 これは、~APIにおいて`禁止~method$や`禁止~header名$を~~合法にするものではない。 ◎ The unsafe-request flag is set by APIs such as fetch() and XMLHttpRequest to ensure a CORS-preflight fetch is done based on the supplied method and header list. It does not free an API from outlawing forbidden methods and forbidden header names.
- `本体@rq( ~NULL )
- ~NULL / `~byte列$ / `本体$。 ◎ A request has an associated body (null, a byte sequence, or a body). Unless stated otherwise it is null.
- 注記: `本体$の中へは、`~fetch$における早期に`~byte列$が安全に抽出されることになる。 この~fieldは、ある種の~redirectに因り,`~HTTP~fetch$の一部として ~NULL に設定され得る。 ◎ A byte sequence will be safely extracted into a body early on in fetch. As part of HTTP fetch it is possible for this field to be set to null due to certain redirects.
- `~client@rq
- ~NULL または`環境~設定群~obj$。 ◎ A request has an associated client (null or an environment settings object).
- `予約-済み~client@rq ( ~NULL )
- ~NULL または `環境$ または `環境~設定群~obj$。 ◎ A request has an associated reserved client (null, an environment, or an environment settings object). Unless stated otherwise it is null.
- 注記: これが利用されるのは、~navi要請, ~worker要請に限られ,~sw要請には利用されない。 それは[ `~navi要請$に対しては `環境$ / ~worker要請に対しては `環境~設定群~obj$ ]を参照する。 ◎ This is only used by navigation requests and worker requests, but not service worker requests. It references an environment for a navigation request and an environment settings object for a worker request.
- `置換する~client~id@rq ( 空~文字列 )
- 文字列。 ◎ A request has an associated replaces client id (a string). Unless stated otherwise it is the empty string.
- 注記: これが利用されるのは、~navi要請に限られる。 それは、`~target閲覧文脈$enVにて`作動中の文書$の`環境~設定群~obj$の`~id$enVになる。 ◎ This is only used by navigation requests. It is the id of the target browsing context’s active document’s environment settings object.
- `~window@rq( `client^l )
- 次のいずれか ⇒# `no-window^l, `client^l, `環境~設定群~obj$のうち[その`大域~obj$enVは `Window$I ~objである]もの ◎ A request has an associated window ("no-window", "client", or an environment settings object whose global object is a Window object). Unless stated otherwise it is "client".
- 注記: `client^l 値は、`~fetching$の間に[ `no-window^l / `要請$の`~client$rq ]に変更される。 この値は、各種~標準が`要請$の`~window$rqを明示的に設定せずに~fetchingを簡便に利用できるようにするためにある。 ◎ The "client" value is changed to "no-window" or request’s client during fetching. It provides a convenient way for standards to not have to explicitly set request’s window.
- `~keepalive@rq( ~F )
- 真偽値。 ◎ A request has an associated boolean keepalive. Unless stated otherwise it is false.
- 注記: これを利用すれば、要請は`環境~設定群~obj$の外で残存できるようになる — 例えば[ `navigator.sendBeacon()$m ~method/~HTML `img$e 要素 / 【~CSPの違反~報告】 ]は、この~flagを ~T にする。 この~flagが ~T にされた要請は、追加的な処理~要件の~subjectになる。 ◎ This can be used to allow the request to outlive the environment settings object, e.g., navigator.sendBeacon and the HTML img element set this flag. Requests with this flag set are subject to additional processing requirements.
- `~sw~mode@rq ( `all^l )
- 次のいずれか ⇒# `all^l, `none^l ◎ A request has an associated service-workers mode, that is "all" or "none". Unless stated otherwise it is "all".
-
注記: これは、どの~swが,この~fetch用の `fetch$et ~eventを受取るかを決定する: ◎ This determines which service workers will receive a fetch event for this fetch.
- `all^l
- 関連な~swが,この~fetch用の `fetch$et ~eventを取得することになる。 ◎ Relevant service workers will get a fetch event for this fetch.
- `none^l
- どの~swも,この~fetch用の~eventは取得しない。 ◎ No service workers will get events for this fetch.
- `起動元@rq( 空~文字列 )
- 次のいずれか ⇒# 空~文字列, `download^l, `imageset^l, `manifest^l, `prefetch^l, `prerender^l, `xslt^l ◎ A request has an associated initiator, which is the empty string, "download", "imageset", "manifest", "prefetch", "prerender", or "xslt". Unless stated otherwise it is the empty string.
- 注記: `要請$の`起動元$rqは、さしあたり 特に細分化されてはいない — 他の仕様からそう要求されてはいないので。 これは~~主に, `CSP$r / `MIX$r を定義し易くするために~~導入された~~用語であり、~JSには公開されない。 ◎ A request’s initiator is not particularly granular for the time being as other specifications do not require it to be. It is primarily a specification device to assist defining CSP and Mixed Content. It is not exposed to JavaScript. [CSP] [MIX]
- `行先@rq( 空~文字列 )
- 次のいずれか ⇒# 空~文字列, `audio^l, `audioworklet^l, `document^l, `embed^l, `font^l, `frame^l, `iframe^l, `image^l, `manifest^l, `object^l, `paintworklet^l, `report^l, `script^l, `serviceworker^l, `sharedworker^l, `style^l, `track^l, `video^l, `worker^l, `xslt^l ◎ A request has an associated destination, which is the empty string, "audio", "audioworklet", "document", "embed", "font", "frame", "iframe", "image", "manifest", "object", "paintworklet", "report", "script", "serviceworker", "sharedworker", "style", "track", "video", "worker", or "xslt". Unless stated otherwise it is the empty string.
-
`要請$の`行先$rqのうち,次に挙げるものは `~scriptに類する@ とされる ⇒# `audioworklet^l, `paintworklet^l, `script^l, `serviceworker^l, `sharedworker^l, `worker^l ◎ A request’s destination is script-like if it is "audioworklet", "paintworklet", "script", "serviceworker", "sharedworker", or "worker".
`~scriptに類する$ものを利用する~algoは、 `xslt^l も考慮するベキである — それも~script実行を生じさせ得るので。 上に挙げていないわけは、常に関連するとは限らず,異なる挙動が要求されることもあるためである。 ◎ Algorithms that use script-like should also consider "xslt" as that too can cause script execution. It is not included in the list as it is not always relevant and might require different behavior.
-
次の一覧は、`要請$の各種[ `起動元$rq, `行先$rq ]が,どの[ ~CSP指令, 特能 ]から利用されるかを描き出したものである。 一覧は、特能に関しては網羅的ではない。 特能には、その仕様にて関連な値が定義される必要がある: ◎ The following table illustrates the relationship between a request’s initiator, destination, CSP directives, and features. It is not exhaustive with respect to features. Features need to have the relevant values defined in their respective standards.
`起動元$rq ◎ Initiator `行先$rq ◎ Destination `~CSP指令$ ◎ CSP directive 特能 ◎ Features "" `report^l - CSP, NEL による報告 `document^l - ~HTMLの`~navigate~algo$(~top-levelに限る) ◎ HTML’s navigate algorithm (top-level only). `frame^l `child-src$dir ~HTMLの `frame$e 要素 `iframe^l `child-src$dir ~HTMLの `iframe$e 要素 "" `connect-src$dir `navigator.sendBeacon()$m, `EventSource$I, ~HTMLの `a ping=""^e, ~HTMLの `area ping=""^e, `fetch()$m, `XMLHttpRequest$I, `WebSocket$I, Cache API【?】 `object^l `object-src$dir ~HTMLの `object$e 要素 `embed^l `object-src$dir ~HTMLの `embed$e 要素 `audio^l `media-src$dir ~HTMLの `audio$e 要素 `font^l `font-src$dir ~CSSの `font-face^at 規則 `image^l `img-src$dir ~HTMLの `img src^e, `/favicon.ico^c 資源, SVG の `image$e 要素, ~CSSの[ `background-image^css, `cursor^css, `list-style-image^css ]~prop, … `audioworklet^l `script-src$dir `audioWorklet.addModule()^m `paintworklet^l `script-src$dir `CSS.paintWorklet.addModule()^m `script^l `script-src$dir ~HTMLの `script$e 要素, `self.importScripts()$m `serviceworker^l `child-src$dir, `script-src$dir, `worker-src$dir `navigator.serviceWorker.register()$m `sharedworker^l `child-src$dir, `script-src$dir, `worker-src$dir `SharedWorker$I `worker^l `child-src$dir, `script-src$dir, `worker-src$dir `Worker$I `style^l `style-src$dir ~HTMLの `link rel=stylesheet^e, ~CSSの `import^at 規則 `track^l `media-src$dir ~HTMLの `track$e 要素 `video^l `media-src$dir ~HTMLの `video$e 要素 `download^l "" - ~HTMLの `download=""^a, “~link先を保存…” UI `imageset^l `image^l `img-src$dir ~HTMLの `img srcset^e, `picture$e 要素 `manifest^l `manifest^l `manifest-src$dir ~HTMLの `link rel=manifest^e 要素 `prefetch^l "" `prefetch-src$dir ~HTMLの `link rel=prefetch^e 要素 `prerender^l 同上 同上 ~HTMLの `link rel=prerender^e 要素 `xslt^l `xslt^l `script-src$dir `<?xml-stylesheet>^c ~CSPの `form-action$dir 指令は、直に ~HTMLの[ ~navigate/~form提出 ]~algoに~hookする必要がある。 ◎ CSP’s form-action needs to be a hook directly in HTML’s navigate or form submission algorithm.
~CSPは、各種~CSP指令~用に,[ `要請$の`~client$rqの`大域~obj$enVに`対応する閲覧文脈$ ]の各 `先祖~閲覧文脈$についても検査する必要がある。 ◎ CSP will also need to check request’s client’s global object’s browsing context’s ancestor browsing contexts for various CSP directives.
- `優先度@rq( ~NULL )
- ~NULL または~UAにより定義される~obj。 【~~説明】 ◎ A request has an associated priority (null or a user-agent-defined object). Unless otherwise stated it is null.
- `生成元@rq( `client^l )
-
`client^l, または `生成元$。 ◎ A request has an associated origin, which is "client" or an origin. Unless stated otherwise it is "client".
- 注記: `client^l は、`~fetching$の間に`生成元$に変化する。 この値は、各種~標準が,`要請$の`生成元$rqを設定せずに~fetchingを簡便に利用できるようにするためにある。 ◎ "client" is changed to an origin during fetching. It provides a convenient way for standards to not have to set request’s origin.
- `~referrer@rq( `client^l )
- 次のいずれか ⇒# `no-referrer^l, `client^l, `~URL$ ◎ A request has an associated referrer, which is "no-referrer", "client", or a URL. Unless stated otherwise it is "client".
- 注記: `client^l は、`~fetching$の間に[ `no-referrer^l / `~URL$ ]に変化する。 この値は、各種~標準が,`要請$の`~referrer$rqを設定せずに~fetchingを簡便に利用できるようにするためにある。 ◎ "client" is changed to "no-referrer" or a URL during fetching. It provides a convenient way for standards to not have to set request’s referrer.
- `~referrer施策@rq( 空~文字列 )
- `~referrer施策$。 `REFERRER$r ◎ A request has an associated referrer policy, which is a referrer policy. Unless stated otherwise it is the empty string. [REFERRER]
- 注記: これは、[ `環境~設定群~obj$に結付けられている~referrer施策 ]を上書きするときに利用できる。 `REFERRER$r ◎ This can be used to override a referrer policy associated with an environment settings object.
- `~mode@rq( `no-cors^l )
- 次のいずれか ⇒# `same-origin^l, `cors^l, `no-cors^l, `navigate^l, `websocket^l ◎ A request has an associated mode, which is "same-origin", "cors", "no-cors", "navigate", or "websocket". Unless stated otherwise, it is "no-cors".
-
注記: これらの値の意味は:
- `same-origin^l
- 要請が同一-生成元~URLになることを確保するために利用される。 要請を同一-生成元~URLにできなかった場合、`~fetch$は`~network~error$を返すことになる。 ◎ Used to ensure requests are made to same-origin URLs. Fetch will return a network error if the request is not made to a same-origin URL.
- `cors^l
- `応答~tainting$rq が `cors^l に設定される要請を`~CORS要請$にする — その事例では、要請された資源が`~CORS~protocol$に[ 解されなかった/意図的に関与しないものである ]場合には,~fetchは`~network~error$を返すことになる。 ◎ For requests whose response tainting gets set to "cors", makes the request a CORS request — in which case, fetch will return a network error if the requested resource does not understand the CORS protocol, or if the requested resource is one that intentionally does not participate in the CORS protocol.
- `no-cors^l
- 要請が[ `~CORS安全とされる~method$, `~CORS安全とされる要請~header$ ]を利用するよう制約する。 成功~時には、~fetchは`不透明な絞込み応答$を返すことになる。 ◎ Restricts requests to using CORS-safelisted methods and CORS-safelisted request-headers. Upon success, fetch will return an opaque filtered response.
- `navigate^l
- これは、文書~間で`~navigate$するときに限り利用される,特別な~modeである。 ◎ This is a special mode used only when navigating between documents.
- `websocket^l
- これは、`~WebSocket~protocol~handshakeを確立する$ときに限り利用される,特別な~modeである。 ◎ This is a special mode used only when establishing a WebSocket connection.
- 注記: `要請$の既定の`~mode$rqは `no-cors^l であるが、標準には,新たな特能には利用しないことが~~強く奨励される。 それは、むしろ安全でない。 ◎ Even though the default request mode is "no-cors", standards are highly discouraged from using it for new features. It is rather unsafe.
- `~CORS予行~利用~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated use-CORS-preflight flag. Unless stated otherwise, it is unset.
-
注記: `~CORS予行~要請$が生じるための条件にはいくつかあるが、[ `~CORS予行~利用~flag$rq ~EQ ~T ]であることは,その 1 つである。 この~flagは、次のいずれかの場合には ~T にされる:
- `XMLHttpRequestUpload$I ~obj上に登録されている~event~listenerがある
- 要請に `ReadableStream$I ~objが利用されている
- `資格証~mode@rq( `same-origin^l )
- 次のいずれか ⇒# `omit^l, `same-origin^l, `include^l ◎ A request has an associated credentials mode, which is "omit", "same-origin", or "include". Unless stated otherwise, it is "same-origin".
-
注記: これらの値の意味は:
- `omit^l
- この要請には、資格証を含めない。 返信された応答~内に資格証が在っても,無視させる。 ◎ Excludes credentials from this request, and causes any credentials sent back in the response to be ignored.
- `same-origin^l
- 同一-生成元~URLにされた要請には、資格証を含める。 同一-生成元~URLから返信された応答~内に資格証が在れば,利用する。 ◎ Include credentials with requests made to same-origin URLs, and use any credentials sent back in responses from same-origin URLs.
- `include^l
- この要請には、常に資格証を含める。 返信された応答~内に資格証が在れば,常に利用する。 ◎ Always includes credentials with this request, and always use any credentials sent back in the response.
- 注記: `要請$の`資格証~mode$rqは、`~fetch$の間,`資格証$の~flowを制御する。 `要請$の`~mode$rq が `navigate^l のときは、その`資格証~mode$rqは `include^l と見做される — 他の値は、現時点では,`~fetch$に織り込まれていない。 `~HTML^cite がここの所で変更された場合、この標準も対応する変更が必要になる。 ◎ Request’s credentials mode controls the flow of credentials during a fetch. When request’s mode is "navigate", its credentials mode is assumed to be "include" and fetch does not currently account for other values. If HTML changes here, this standard will need corresponding changes.
- `資格証利用URL~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated use-URL-credentials flag. Unless stated otherwise, it is unset.
- `~cache~mode@rq( `default^l )
- 次のいずれか ⇒# `default^l, `no-store^l, `reload^l, `no-cache^l, `force-cache^l, `only-if-cached^l ◎ A request has an associated cache mode, which is "default", "no-store", "reload", "no-cache", "force-cache", or "only-if-cached". Unless stated otherwise, it is "default".
- 注記:
- `default^l
-
`~fetch$は、~networkへ向かうに先立ち,~HTTP~cacheを検分する。 ~HTTP~cache内に要請に合致している[ (1) `新鮮な応答$が在る / (2) `~stale-while-revalidate応答$が在る/ (3) `非新鮮な応答$が在る / (4) 応答は無い ]とするとき:
- (1) / (2) の場合、合致したそれを返す。
- (2) の場合、条件付き~network~fetchも為して,対する応答で~HTTP~cache内の合致したそれを更新する。
- (3) の場合、条件付き~network~fetchを為して,対する応答で~HTTP~cache内の合致したそれを更新した上で,その結果を返す。
- (4) の場合、条件付きでない~network~fetchを為して,対する応答を返した上で,その応答で~HTTP~cacheも更新する。
`HTTP$r `HTTP-SEMANTICS$r `HTTP-COND$r `HTTP-CACHING$r `HTTP-AUTH$r `STALE-WHILE-REVALIDATE$r
◎ Fetch will inspect the HTTP cache on the way to the network. If the HTTP cache contains a matching fresh response it will be returned. If the HTTP cache contains a matching stale-while-revalidate response it will be returned, and a conditional network fetch will be made to update the entry in the HTTP cache. If the HTTP cache contains a matching stale response, a conditional network fetch will be returned to update the entry in the HTTP cache. Otherwise, a non-conditional network fetch will be returned to update the entry in the HTTP cache. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH] [STALE-WHILE-REVALIDATE] - `no-store^l
- ~fetchは、~HTTP~cacheが全く無かったかのように挙動する。 ◎ Fetch behaves as if there is no HTTP cache at all.
- `reload^l
- ~fetchは、~networkへ向かう際には,~HTTP~cacheが全く無かったかのように挙動する。 それがため、通常の要請を作成して,対する応答で~HTTP~cacheを更新する。 ◎ Fetch behaves as if there is no HTTP cache on the way to the network. Ergo, it creates a normal request and updates the HTTP cache with the response.
- `no-cache^l
- ~fetchは、~HTTP~cache内に要請に合致する応答が[ 在れば `条件付き要請$ / 無ければ 通常の要請 ]を作成した上で、対する応答で~HTTP~cacheを更新する。 ◎ Fetch creates a conditional request if there is a response in the HTTP cache and a normal request otherwise. It then updates the HTTP cache with the response.
- `force-cache^l
- ~fetchは、~HTTP~cache内に要請に合致する応答が在れば,それが非新鮮であっても利用する。 応答が無ければ、通常の要請を作成して,対する応答で~HTTP~cacheを更新する。 ◎ Fetch uses any response in the HTTP cache matching the request, not paying attention to staleness. If there was no response, it creates a normal request and updates the HTTP cache with the response.
- `only-if-cached^l
- ~fetchは、~HTTP~cache内に要請に合致する応答が在れば,それが非新鮮であっても利用する。 応答が無ければ、~network~errorを返す。 (利用できるのは、[ `要請$の`~mode$rq ~EQ `same-origin^l ]の場合に限られる。 ~cacheされた~redirectは、[ `要請$の`~redirect~mode$rq ~EQ `follow^l ]~AND[ どの~redirectも`要請$の`~mode$rqに違反しない ]と見做す下で,追従することになる。) ◎ Fetch uses any response in the HTTP cache matching the request, not paying attention to staleness. If there was no response, it returns a network error. (Can only be used when request’s mode is "same-origin". Any cached redirects will be followed assuming request’s redirect mode is "follow" and the redirects do not violate request’s mode.)
`~cache~mode$rqが `default^l の場合、`~header~list$rq内に[ 次のいずれかを`名前に持つ~header$ ]が在るならば,`~fetch$により `no-store^l に設定される ⇒# `If-Modified-Since$h, `If-None-Match$h, `If-Unmodified-Since$h, `If-Match$h, `If-Range$h ◎ If header list contains `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match`, or `If-Range`, fetch will set cache mode to "no-store" if it is "default".
- `~redirect~mode@rq( `follow^l )
- 次のいずれか ⇒# `follow^l, `error^l, `manual^l ◎ A request has an associated redirect mode, which is "follow", "error", or "manual". Unless stated otherwise, it is "follow".
-
注記: これらの値の意味は:
- `follow^l
- 資源の~fetch時に被ったすべての~redirectに追従する。 ◎ Follow all redirects incurred when fetching a resource.
- `error^l
- 要請が~redirectに出くわしたときには、`~network~error$を返す。 ◎ Return a network error when a request is met with a redirect.
- `manual^l
- 要請が~redirectに出くわしたときには、~swが当の~redirectを~offlineで再生し直すのを許容するため,`不透明~redirect絞込み応答$を検索取得する。 他の場合、`~HTTP~redirectの不可分な取扱い$に違反しないよう,応答は`~network~error$と判別-不能になる。 ◎ Retrieves an opaque-redirect filtered response when a request is met with a redirect, to allow a service worker to replay the redirect offline. The response is otherwise indistinguishable from a network error, to not violate atomic HTTP redirect handling.
- `完全性~metadata@rq(空~文字列)
- 文字列。 ◎ A request has associated integrity metadata (a string). Unless stated otherwise, it is the empty string.
- 【 ~fetchした結果の~dataが,要請する側が期待する~dataと正確に一致するかどうか検証するための~data。 `SRI$r 】
- `暗号用~nonce~metadata@rq(空~文字列)
- 文字列。 ◎ A request has associated cryptographic nonce metadata (a string). Unless stated otherwise, it is the empty string.
- `構文解析器~metadata@rq(空~文字列)
- 次のいずれか ⇒# 空~文字列, `parser-inserted^l, `not-parser-inserted^l ◎ A request has associated parser metadata which is the empty string, "parser-inserted", or "not-parser-inserted". Unless otherwise stated, it is the empty string.
- 【 例えば,~scriptが構文解析-時に挿入されたものかどうかを表す。 】
- 注記: `要請$の[ `暗号用~nonce~metadata$rq, `構文解析器~metadata$rq ]は,一般に、`要請$を作成する責を負う~HTML要素~上の各種[ 属性, ~flag ]から拡充される【~HTMLの`~script~fetch~options$も見よ】。 これらは、~CSPの各種~algoにおいて,所与の文脈の下で[ 要請, または応答 ]を阻止するかどうか決定するために利用される。 `CSP$r ◎ A request’s cryptographic nonce metadata and parser metadata are generally populated from attributes and flags on the HTML element responsible for creating a request. They are used by various algorithms in Content Security Policy to determine whether requests or responses are to be blocked in a given context. [CSP]
- `~reload~navi~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated reload-navigation flag. Unless stated otherwise, it is unset.
- 注記: この~flagは、~HTMLの`~navigate~algo$により排他的に利用される。 `HTML$r ◎ This flag is for exclusive use by HTML’s navigate algorithm. [HTML]
- `履歴~navi~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated history-navigation flag. Unless stated otherwise, it is unset.
- 注記: この~flagは、~HTMLの`~navigate~algo$により排他的に利用される。 `HTML$r ◎ This flag is for exclusive use by HTML’s navigate algorithm. [HTML]
- `~tainted生成元~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated tainted origin flag. Unless stated otherwise, it is unset.
- `~URL~list@rq( « `要請$の`~URL$rqの複製 » )
- 1 個~以上の`~URL$からなる`~list$。 ◎ A request has an associated URL list (a list of one or more URLs). Unless stated otherwise, it is a list containing a copy of request’s URL.
- `現在の~URL@rq
- `~URL~list$rq内の最後の`~URL$を指す。 ◎ A request has an associated current URL. It is a pointer to the last URL in request’s URL list.
- `~redirect数@rq( 0 )
- 負でない整数。 【~redirectが生じた回数】 ◎ A request has an associated redirect count. Unless stated otherwise, it is zero.
- `応答~tainting@rq( `basic^l )
- 次のいずれか ⇒# `basic^l, `cors^l, `opaque^l ◎ A request has an associated response tainting, which is "basic", "cors", or "opaque". Unless stated otherwise, it is "basic".
- 【 この要請に対する応答は、何に “~~染まる” か。 ~security用の制限を与える(`絞込み応答$の種類として反映されることになる)。 】
- `~no-cache時に~cache制御~headerを改変しない~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated prevent no-cache cache-control header modification flag. Unless stated otherwise, it is unset.
- `~done~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated done flag. Unless stated otherwise, it is unset.
- `計時許容に失敗した~flag@rq( ~F )
- 真偽値。 ◎ A request has an associated timing allow failed flag. Unless stated otherwise, it is unset.
注記: `要請$の次に挙げるものは、`~fetch$ ~algoの内部状態管理~用に利用される ⇒# `~tainted生成元~flag$rq, `~URL~list$rq, `現在の~URL$rq, `~redirect数$rq, `応答~tainting$rq, `~done~flag$rq, `計時許容に失敗した~flag$rq ◎ A request’s tainted origin flag, URL list, current URL, redirect count, response tainting, done flag, and timing allow failed flag are used as bookkeeping details by the fetch algorithm.
`下位資源~要請@ とは、次のいずれかを`行先$rqとする`要請$である ⇒# `audio^l, `audioworklet^l, `font^l, `image^l, `manifest^l, `paintworklet^l, `script^l, `style^l, `track^l, `video^l, `xslt^l, 空~文字列 ◎ A subresource request is a request whose destination is "audio", "audioworklet", "font", "image", "manifest", "paintworklet", "script", "style", "track", "video", "xslt", or the empty string.
`非~下位資源~要請@ とは、次のいずれかを`行先$rqとする`要請$である ⇒# `document^l, `embed^l, `frame^l, `iframe^l, `object^l, `report^l, `serviceworker^l, `sharedworker^l, `worker^l ◎ A non-subresource request is a request whose destination is "document", "embed", "frame", "iframe", "object", "report", "serviceworker", "sharedworker", or "worker".
【 `下位資源~要請$ではないが、論理的な否定 — すべての要請のうち,下位資源~要請ではないもの — でもないことに注意。 】
`~navi要請@ とは、次を`行先$rqとする`要請$である ⇒# `document^l, `embed^l, `frame^l, `iframe^l, `object^l, ◎ A navigation request is a request whose destination is "document", "embed", "frame", "iframe", or "object".
注記: これらの用語の用法については`~fetchを取扱う$を見よ。 `SW$r ◎ See handle fetch for usage of these terms. [SW]
`要請の生成元を直列化する@ ときは、所与の ( `要請$ %要請 ) に対し,次を走らす: ◎ Serializing a request origin, given a request request, is to run these steps:
- ~IF[ %要請 の`~tainted生成元~flag$rq ~EQ ~T ] ⇒ ~RET `null^l ◎ If request’s tainted origin flag is set, then return "null".
- ~RET `生成元を直列化する$( %要請 の`生成元$rq ) ◎ Return request’s origin, serialized.
`要請の生成元を~byte直列化する@ ときは、所与の ( `要請$ %要請) に対し,次の結果を返す ⇒ `同型に符号化する$( `要請の生成元を直列化する$( %要請 ) ) ◎ Byte-serializing a request origin, given a request request, is to return the result of serializing a request origin with request, isomorphic encoded.
`要請を~cloneする@ ときは、所与の ( `要請$ %要請 ) に対し,次を走らす: ◎ To clone a request request, run these steps:
- %新~要請 ~LET %要請 の`本体$rqを除いた部分の複製 ◎ Let newRequest be a copy of request, except for its body.
- ~IF[ %要請 の`本体$rq ~NEQ ~NULL ] ⇒ %新~要請 の`本体$rq ~SET `本体を~cloneする$( %要請 の`本体$rq ) ◎ If request’s body is non-null, set newRequest’s body to the result of cloning request’s body.
- ~RET %新~要請 ◎ Return newRequest.
`範囲~headerを追加する@ ときは、所与の ( `要請$ %要請, 整数 %先頭, 整数 %末尾 (省略時は ε )) に対し,次を走らす: ◎ To add a range header to a request request, with an integer first, and an optional integer last, run these steps:
- %範囲~値 ~LET `bytes ^bl ◎ Let rangeValue be `bytes `.
- %範囲~値 に次の結果を付加する ⇒ `同型に符号化する$( `整数を直列化する$( %先頭 ) ) ◎ Serialize and isomorphic encode first, and append the result to rangeValue.
- %範囲~値 に `2D^X ( `-^bl )を付加する ◎ Append 0x2D (-) to rangeValue.
- ~IF[ %末尾 ~NEQ ε ] ⇒ %範囲~値 に次の結果を付加する ⇒ `同型に符号化する$( `整数を直列化する$( %末尾 ) ) ◎ If last is given, then serialize and isomorphic encode it, and append the result to rangeValue.
- %要請 の`~header~list$rqに`~headerを付加する$( `Range$h / %範囲~値 ) ◎ Append `Range`/rangeValue to request’s header list.
注記: 範囲~headerが表す~byte範囲は、先頭, 末尾も含む。 ( %先頭, %末尾 ) ~EQ ( 0, 500 ) ならば 501 個の~byteからなる範囲になる。 ◎ A range header denotes an inclusive byte range. There a range header where first is 0 and last is 500, is a range of 501 bytes.
注記: 複数の応答を 1 個の論理的な資源に組合せる特能は、歴史的に~security~bugの源になる。 部分的~応答に対処する特能に対する~security考査を探されたし。 ◎ Features that combine multiple responses into one logical resource are historically a source of security bugs. Please seek security review for features that deal with partial responses.
`応答~URLを報告-用に直列化する@ ときは、所与の ( `応答$ %応答 ) に対し,次を走らす: ◎ To serialize a response URL for reporting, given a response response, run these steps:
- %応答 の`~URL~list$rsは`空$でない ◎ Assert: response’s URL list is not empty.
-
%~url ~LET %応答 の`~URL~list$rs[ 0 ] の複製 ◎ Let url be a copy of response’s URL list’s first element.
注記: ~redirect~targetについての情報が漏洩するのを避けるため、これは, %応答 の`~URL$rsではない( ~CSP報告-用の類似な考慮点 も見よ)。 `CSP$r ◎ This is not response’s URL in order to avoid leaking information about redirect targets (see similar considerations for CSP reporting too). [CSP]
- `~URLの~usernameを設定する$( %~url, 空~文字列 ) ◎ Set the username given url and the empty string.
- `~URLの~passwordを設定する$( %~url, 空~文字列 ) ◎ Set the password given url and the empty string.
- ~RET `~URLを直列化する$( %~url, `素片は除外する$i ) ◎ Return the serialization of url with exclude fragment set to true.
2.2.6. 応答
`応答@ ( `response^en )とは、`~fetch$の結果である。 `応答$は、時間とともに発展していくものであり,その各種~fieldすべてが直ぐに可用になるわけではない。 ◎ The result of fetch is a response. A response evolves over time. That is, not all its fields are available straight away.
各 `応答$には、以下に挙げるものが結付けられる。 各~項には,それがとり得る値の種類を示す。 他が言明されない限り、[ 見出しの括弧内に与える値 ]を既定~値としてとるものとする: ◎ ↓
- `種別@rs( `default^l )
- 次のいずれか ⇒# `basic^l, `cors^l, `default^l, `error^l, `opaque^l, `opaqueredirect^l ◎ A response has an associated type which is "basic", "cors", "default", "error", "opaque", or "opaqueredirect". Unless stated otherwise, it is "default".
- `中止~flag@rs( ~F )
- 真偽値。 ◎ A response can have an associated aborted flag, which is initially unset.
- 注記: これは、 ~T ならば[ 開発者/末端利用者 ]が要請を意図的に中止したことを指示する。 ◎ This indicates that the request was intentionally aborted by the developer or end-user.
- `~URL@rs
- `~URL~list$rsを成す最後の`~URL$を指す — `~URL~list$rsが`空$ならば ~NULL とする。 ◎ A response has an associated URL. It is a pointer to the last URL in response’s URL list and null if response’s URL list is empty.
- `~URL~list@rs( 空~list )
- 0 個~以上の`~URL$からなる`~list$。 ◎ A response has an associated URL list (a list of zero or more URLs). Unless stated otherwise, it is the empty list.
- 注記: この~listは、最後の`~URL$を除いて,~scriptには公開されない — そうすると`~HTTP~redirectの不可分な取扱い$に違反するので。 ◎ Except for the last URL, if any, a response’s URL list is not exposed to script as that would violate atomic HTTP redirect handling.
- `状態s@rs( `200$st )
- `状態s$。 ◎ A response has an associated status, which is a status. Unless stated otherwise it is 200.
- `状態s~message@rs( 空`~byte列$ )
- `~byte列$。 ◎ A response has an associated status message. Unless stated otherwise it is the empty byte sequence.
- 注記: HTTP/2 接続~越しの応答においては、その状態s~messageは,常に空~byte列になる — HTTP/2 はそれを~supportしないので。 ◎ Responses over an HTTP/2 connection will always have the empty byte sequence as status message as HTTP/2 does not support them.
- 【 HTTP/1.x の文脈では,応答の `reason-phrase$p を表現する。 】
- `~header~list@rs(空~list)
- `~header~list$。 ◎ A response has an associated header list (a header list). Unless stated otherwise it is empty.
- `本体@rs( ~NULL )
- ~NULL または`本体$。 ◎ A response has an associated body (null or a body). Unless stated otherwise it is null.
- `~cache状態@rs( 空~文字列 )
- 次のいずれか ⇒# 空~文字列, `local^l ◎ A response has an associated cache state (the empty string or "local"). Unlesss stated otherwise, it is the empty string.
- 注記: これは もっぱら、~sw用途に意図される `SW$r ◎ This is intended solely for usage by service workers. [SW]
- `~CSP~list@rs(空~list)
- `応答$用の`~CSP~obj$の`~list$。 `CSP$r ◎ A response has an associated CSP list, which is a list of Content Security Policy objects for the response. The list is empty unless otherwise specified. [CSP]
- `~CORSに公開される~header名~list@rs(空~list)
- 0 個以上の`~header$の`名前$hdからなる~list。 ◎ A response has an associated CORS-exposed header-name list (a list of zero or more header names). The list is empty unless otherwise specified.
- 注記: `応答$の`~CORSに公開される~header名~list$rsは、概して `Access-Control-Expose-Headers$h ~headerから`値を抽出-$した結果に設定されることになる。 この~listは、`~CORS絞込み応答$において公開する~headerを決定するときに利用される。 ◎ A response will typically get its CORS-exposed header-name list set by extracting header values from the `Access-Control-Expose-Headers` header. This list is used by a CORS filtered response to determine which headers to expose.
- `範囲が要請された~flag@rs ( ~F )
- 真偽値。 ◎ A response has an associated range-requested flag, which is initially unset.
- 注記: これは、[ 過去の範囲~付き要請からの部分的~応答が,範囲~要請を為していなかった~APIに供される ]ことを防止することを確保するために利用される。 この~flagの用途については、その攻撃の詳細な記述を見よ。 ◎ This is used to ensure to prevent a partial response from an earlier ranged request being provided to an API that didn’t make a range request. See the flag’s usage for a detailed description of the attack.
- `計時許容に合格した~flag@rs ( ~F )
- 真偽値。 ◎ A response has an associated timing allow passed flag, which is initially unset.
- 注記: これは、~fetchの~call元が,[ 返された応答の~flagを調べて,~fetchされた資源~上で敏感な計時~dataは許容されるかどうか決定できるようにする ]ために利用される。 この~flagはまた,~redirectの応答~上では[ ~redirect連鎖における直前の応答にて ~T ]ならば ~T に設定する必要があるので、この~flagは,要請の`計時許容に失敗した~flag$rqを利用して内部的に追跡される。 ◎ This is used so that the caller to a fetch can determine if sensitive timing data is allowed on the resource fetched by looking at the flag of the response returned. Because the flag on the response of a redirect has to be set if it was set for previous responses in the redirect chain, this is also tracked internally using the request’s timing allow failed flag.
次を満たす`応答$は、 `中止~network~error@ と呼ばれる ⇒ [ `~network~error$である ]~AND[ `中止~flag$rs ~EQ ~T ] ◎ A response whose type is "error" and aborted flag is set is known as an aborted network error.
次を満たす`応答$は、 `~network~error@ と呼ばれる ⇒ `種別$rs ~EQ `error^l ◎ A response whose type is "error" is known as a network error.
`~network~error$は,常に次をすべて満たすようにされる:
- `状態s$rs ~EQ 0
- `状態s~message$rs ~EQ 空~byte列
- `~header~list$rsは空である
- `本体$rs ~EQ ~NULL
`絞込み応答@ とは、`~network~error$でない ある`応答$を,その一部分に制限して公開する~viewである。 その応答を指して,`絞込み応答$の `内部~応答@ という。 ◎ A filtered response is a limited view on a response that is not a network error. This response is referred to as the filtered response’s associated internal response.
注記: `~fetch$ ~algoは、~APIが不用意に情報を漏洩させなくするために,その種の~viewを返す。 旧来の理由から,情報を公開させる必要がある場合 — 例:画像~dataを復号器に渡すためなど — は、結付けられている`内部~応答$を利用できる。 内部~応答は、仕様の内部~algoからのみ “~access可能” であり,決して`絞込み応答$自身にはならない。 ◎ The fetch algorithm returns such a view to ensure APIs do not accidentally leak information. If the information needs to be exposed for legacy reasons, e.g., to feed image data to a decoder, the associated internal response can be used, which is only "accessible" to internal specification algorithms and is never a filtered response itself.
`基本~絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `basic^l
- `~header~list$rsは、`内部~応答$の`~header~list$rsから 次に該当する`~header$は除外したものからなる ⇒ `名前$hdは `禁止~応答~header名$である
`~CORS絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `cors^l
- `~header~list$rsは、`内部~応答$の`~CORSに公開される~header名~list$rsから 次に該当する`~header$は除外したものからなる ⇒ `名前$hdは`~CORS安全とされる応答~header名$でない
`不透明な絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `opaque^l
- `~URL~list$rsは空である
- `状態s$rs ~EQ 0
- `状態s~message$rs ~EQ 空~byte列
- `~header~list$rsは空である
- `本体$rs ~EQ ~NULL
`不透明~redirect絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `opaqueredirect^l
- `状態s$rs ~EQ 0
- `状態s~message$rs ~EQ 空~byte列
- `~header~list$rsは空である
- `本体$rs ~EQ ~NULL
`不透明~redirect絞込み応答$に対しては、~redirectは後続しないので,`~URL~list$rsが公開されても無害である。 ◎ Exposing the URL list for opaque-redirect filtered responses is harmless since no redirects are followed.
言い換えれば、[ `不透明な絞込み応答$, `不透明~redirect絞込み応答$ ]と`~network~error$とは,ほとんど判別できない。 新たな~APIを導入する際には、情報を漏洩させなくするため,仕様の内部~algoには `内部~応答$を利用しないこと。 ◎ In other words, an opaque filtered response and an opaque-redirect filtered response are nearly indistinguishable from a network error. When introducing new APIs, do not use the internal response for internal specification algorithms as that will leak information.
これはまた、 `response.ok$m などの~JS~APIが返す結果は,およそ役に立たないことを意味する。 ◎ This also means that JavaScript APIs, such as response.ok, will return rather useless results.
`応答を~cloneする@ ときは、所与の ( `応答$ %応答 ) に対し,次を走らす: ◎ To clone a response response, run these steps:
- ~IF[ %応答 は`絞込み応答$である ] ⇒ ~RET 次のようにされた新たな`絞込み応答$ ⇒# `内部~応答$ ~SET `応答を~cloneする$( %応答 の`内部~応答$ ); 他の部分は %応答 と一致する ◎ If response is a filtered response, then return a new identical filtered response whose internal response is a clone of response’s internal response.
- %新~応答 ~LET %応答 の`本体$rsを除いた部分の複製 ◎ Let newResponse be a copy of response, except for its body.
- ~IF[ %応答 の`本体$rs ~NEQ ~NULL ] ⇒ %新~応答 の`本体$rs ~SET `本体を~cloneする$( %応答 の`本体$rs ) ◎ If response’s body is non-null, then set newResponse’s body to the result of cloning response’s body.
- ~RET %新~応答 ◎ Return newResponse.
`新鮮な応答@ とは、次を満たす`応答$である ⇒ `現在の齢$は`鮮度~維持期間$を過ぎていない ◎ A fresh response is a response whose current age is within its freshness lifetime.
`~stale-while-revalidate応答@ とは、次を満たす`応答$である ⇒ [ `新鮮な応答$でない ]~AND[ `現在の齢$は`~stale-while-revalidate維持期間$を過ぎていない ] ◎ A stale-while-revalidate response is a response that is not a fresh response and whose current age is within the stale-while-revalidate lifetime.
【 ~stale-while-revalidate `Cache-Control$h 指令を伴わない応答は、該当し得ないことになる(維持期間は “無い” ので)。 】
`非新鮮な応答@ とは、次を満たす`応答$である ⇒ [ `新鮮な応答$でない ]~AND[ `~stale-while-revalidate応答$でない ] ◎ A stale response is a response that is not a fresh response or a stale-while-revalidate response.
【 ~HTTPが定義する非新鮮 (新鮮の否定)より狭義になる。 】
`~Location~URLを得る@ ときは、所与の ( `応答$ %応答, ~NULLまたは`~ASCII文字列$ %要請~素片 ) に対し,[ ~NULL / `失敗^i / `~URL$ ]を返す: ◎ The location URL of a response response, given null or an ASCII string requestFragment, is the value returned by the following steps. They return null, failure, or a URL.
- ~IF[ %応答 の`状態s$rsは`~redirect状態s$でない ] ⇒ ~RET ~NULL ◎ If response’s status is not a redirect status, then return null.
- %~Location ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Location$h ) ◎ Let location be the result of extracting header list values given `Location` and response’s header list.
-
~IF[ %~Location は`値$hdである ] ⇒ %~Location ~SET `~URL構文解析する$( %~Location, %応答 の`~URL$rs ) ◎ If location is a value, then set location to the result of parsing location with response’s URL.
注記: %応答 が `new Response()$m 構築子を通して構築されていた場合、 %応答 の`~URL$rsは ~NULL になる — その結果, %~Location が成功裡に構文解析されるのは、それが`素片~付き絶対~URL文字列$である場合に限られることになる。 ◎ If response was constructed through the Response constructor, response’s URL will be null, meaning that location will only parse successfully if it is an absolute-URL-with-fragment string.
-
~IF[ %~Location は`~URL$である ]~AND[ %~Location の`素片$url ~EQ ~NULL ] ⇒ %~Location の`素片$url ~SET %要請~素片 ◎ If location is a URL whose fragment is null, then set location’s fragment to requestFragment.
注記: この段は、合成な応答【構築子を通して構築されたそれ】が(~~実際,すべてのそれが)[ ~HTTPにより定義される~redirectに対し,その処理~modelに従う ]ことを確保する。 `HTTP-SEMANTICS$r ◎ This ensures that synthetic (indeed, all) responses follow the processing model for redirects defined by HTTP. [HTTP-SEMANTICS]
- ~RET %~Location ◎ Return location.
注記: `~Location~URLを得る$ ~algoが利用されるのは、次のいずれか以外にない ⇒# この標準における~redirectの取扱い/ `~HTML^cite `HTML$r の~navigate~algo†(それは、~redirectを手動で取扱う) 【†特に、その中で`~navigate~fetchを処理する$とき。】 ◎ The location URL algorithm is exclusively used for redirect handling in this standard and in HTML’s navigate algorithm which handles redirects manually. [HTML]
2.2.7. その他
`行先の素@ ( `potential destination^en )は、次のいずれかである:
- `fetch^l
- 空~文字列でない`行先$rq
`行先の素$ %行先の素 を `行先に翻訳する@ ときは、次を走らす: ◎ To translate a potential destination potentialDestination, run these steps:
- ~IF[ %行先の素 ~EQ `fetch^l ] ⇒ ~RET 空~文字列 ◎ If potentialDestination is "fetch", then return the empty string.
- ~Assert: %行先の素 は`行先$rqである ◎ Assert: potentialDestination is a destination.
- ~RET %行先の素 ◎ Return potentialDestination.
2.3. 認証~entry
`認証~entry@ / `~proxy認証~entry@ は、[ ~HTTP認証/~HTTP~proxy認証 ]に利用される[ ~username, ~password, ~realm† ]の組であり,1 つ以上の`要請$に結付けられる。 【† ~HTTP仕様の~realm 】 ◎ An authentication entry and a proxy-authentication entry are tuples of username, password, and realm, used for HTTP authentication and HTTP proxy authentication, and associated with one or more requests.
~UAは、[ ~HTTP~cookieと, それに類する追跡~機能性 ]が一緒に消去されることを,許容するベキである。 ◎ User agents should allow both to be cleared together with HTTP cookies and similar tracking functionality.
更なる詳細は~HTTPにて定義される。 `HTTP$r `HTTP-SEMANTICS$r `HTTP-COND$r `HTTP-CACHING$r `HTTP-AUTH$r ◎ Further details are defined by HTTP. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]
2.4. ~fetch~group
各 `環境~設定群~obj$には、 `~fetch~group@ が結付けられる。 ◎ Each environment settings object has an associated fetch group.
各`~fetch~group$は、いくつかの `~fetch記録@ からなる,有順序~listを保持する。 ◎ A fetch group holds an ordered list of fetch records.
各`~fetch記録$には、次に挙げるものが結付けられる: ◎ ↓
- `要請@fg
- `要請$。 ◎ A fetch record has an associated request (a request).
- `~fetch@fg
- `~fetch$~algoの~instance, または ~NULL 。 ◎ A fetch record has an associated fetch (a fetch algorithm or null).
`~fetch~group$ %G が `終了され@fg たときは、次を走らす ⇒ %G 内の ~EACH( `~fetch記録$ %記録 ) に対し ⇒ ~IF[ %記録 の`要請$fgは[[ `~done~flag$rq ~EQ ~F ]~OR[ `~keepalive$rq ~EQ ~F ]]を満たす ] ⇒ %記録 の`~fetch$fgを`終了させる$() ◎ When a fetch group is terminated, for each associated fetch record whose request’s done flag is unset or keepalive is false, terminate the fetch record’s fetch.
2.5. 接続
各~UAには `接続~pool@ が結付けられる。 `接続~pool$は、 0 個以上の `接続@ からなる。 各 `接続$は、 ( `key^cN(`~network区分~key$), `origin^cN(`生成元$), `credentials^cN(真偽値) ) が成す組で識別される。 ◎ A user agent has an associated connection pool. A connection pool consists of zero or more connections. Each connection is identified by a key (a network partition key), an origin (an origin), and credentials (a boolean).
`接続を得する@ ときは、所与の ( %~key, %生成元, %資格証 ) に対し,次を走らす: ◎ To obtain a connection, given a key, origin, and credentials, run these steps:
- ~IF[ ~UAの`接続~pool$内に[ ( `key^cN, `origin^cN, `credentials^cN ) ~EQ ( %~key, %生成元, %資格証 ) ]を満たす`接続$はある ] ⇒ ~RET その`接続$ ◎ If the user agent’s connection pool contains a connection whose key is key, origin is origin, and credentials is credentials, then return that connection.
- %接続 ~LET ~NULL ◎ Let connection be null.
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- %接続 ~SET %生成元 への~HTTP接続を確立しようと~~試みた結果 `HTTP$r `HTTP-SEMANTICS$r `HTTP-COND$r `HTTP-CACHING$r `HTTP-AUTH$r `TLS$r — ただし ⇒ [ %資格証 ~EQ ~F ]の場合は、~TLS~client証明書は`送信しない^emこと ◎ Set connection to the result of establishing an HTTP connection to origin. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH] [TLS] • If credentials is false, then do not send a TLS client certificate.
- ~IF[ 接続の確立ngに成功しなかった(例: DNS/TCP/TLS の~error) ] ⇒ ~RET `失敗^i ◎ If establishing a connection does not succeed (e.g., a DNS, TCP, or TLS error), then return failure.
-
前~段が`中止されたときは$: ◎ If aborted, then:
- ~IF[ %接続 ~NEQ ~NULL ] ⇒ %接続 を~closeする ◎ If connection is not null, then close connection.
- ~RET `失敗^i ◎ Return failure.
- ~UAの`接続~pool$に,次のようにされた %接続 を追加する ⇒ ( `key^cN, `origin^cN, `credentials^cN ) ~SET ( %~key, %生成元, %資格証 ) ◎ Add connection to the user agent’s connection pool with key being key, origin being origin, and credentials being credentials.
- ~RET %接続 ◎ Return connection.
注記: これは,意図的にやや曖昧にされている — 細かい点で,まだ発展し続けているので。 これを述べることは、 `link rel=preconnect^e による特能を説明する助けになり、また,`接続$は `credentials^cN 別に分けられることを明瞭に~~規定する。 後者は、例えば~TLS~session識別子が[ `credentials^cN ~EQ ~F の`接続$ ]と[ ~EQ ~T のそれ ]とにまたがって再利用されないことを明確化する。 ◎ This is intentionally a little vague as the finer points are still evolving. Describing this helps explain the <link rel=preconnect> feature and clearly stipulates that connections are keyed on credentials. The latter clarifies that e.g., TLS session identifiers are not reused across connections whose credentials are false with connections whose credentials are true.
【! See https://github.com/whatwg/fetch/issues/114#issuecomment-143500095 for when we make WebSocket saner 】2.6. ~network区分~key
`~network区分~key@ は、次の 2 つからなる~tupleである ⇒ ( `~site$, ~NULL または`実装定義$な値 ) ◎ A network partition key is a tuple consisting of a site and null or an implementation-defined value.
`~network区分~keyを決定する@ ときは、所与の ( %要請 ) に対し,次の手続きを走らす: ◎ To determine the network partition key, given request, run these steps:
- %~top-level生成元 ~LET ~NULL ◎ Let topLevelOrigin be null.
-
~IF[ %要請 の`予約-済み~client$rq ~NEQ ~NULL ]: ◎ If request’s reserved client is non-null, then:
- %~top-level生成元 ~SET %要請 の`予約-済み~client$rqの`~top-level生成元$enV ◎ Set topLevelOrigin to request’s reserved client’s top-level origin.
-
~IF[ %~top-level生成元 ~EQ ~NULL ] ⇒ %~top-level生成元 ~SET %要請 の`予約-済み~client$rqの`~top-level作成時の~URL$enVの`生成元$url ◎ If topLevelOrigin is null, then set topLevelOrigin to request’s reserved client’s top-level creation URL’s origin.
注記: これが起こるのは、~top-level~naviに限られる。 ◎ This happens for top-level navigations only.
- ~ELIF[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ %~top-level生成元 ~SET %要請 の`~client$rqの`~top-level生成元$enV ◎ Otherwise, if request’s client is non-null, set topLevelOrigin to request’s client’s top-level origin.
- ~ELSE ⇒ ~RET ~NULL ◎ Otherwise, return null.
- ~Assert: %~top-level生成元 は`生成元$である ◎ Assert: topLevelOrigin is an origin.
- %~top-level~site ~LET `~siteを得する$( %~top-level生成元 ) ◎ Let topLevelSite be the result of obtaining a site, given topLevelOrigin.
-
%第二~key ~LET ~NULL または`実装定義$な値 ◎ Let secondKey be null or an implementation-defined value.
第二~keyは、意図的に少し曖昧にされている — より精緻な点で、依然として発展しているので。 課題 #1035 を見よ。 ◎ The second key is intentionally a little vague as the finer points are still evolving. See issue #1035.
- ~RET ( %~top-level~site, %第二~key ) ◎ Return (topLevelSite, secondKey).
2.7. ~HTTP~cache区分
`~HTTP~cache区分を決定する@ ときは、所与の ( %要請 ) に対し,次の手続きを走らす: ◎ To determine the HTTP cache partition, given request, run these steps:
- %~key ~LET `~network区分~keyを決定する$( %要請 ) ◎ Let key be the result of determining the network partition key given request.
- ~IF[ %~key ~EQ ~NULL ] ⇒ ~RET ~NULL ◎ If key is null, then return null.
- ~RET %~key に結付けられている一意な~HTTP~cache `HTTP-CACHING$r ◎ Return the unique HTTP cache associated with key. [HTTP-CACHING]
2.8. ~portの阻止-法
注記: 新たな~protocolは、[ ~ALPNを利用している~TLS ]を通して折衝することにより,~portを阻止する必要を避けれる。 その事例では、~protocolは,~HTTP要請を通して偽装し得なくなる。 `RFC7301$r ◎ New protocols can avoid the need for blocking ports by negotiating the protocol through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in that case. [RFC7301]
`要請$ %要請 の `~fetchingは,不良~portに因り阻止されるべきか?@ どうか決定するときは、次を走らす: ◎ To determine whether fetching a request request should be blocked due to a bad port, run these steps:
- %~url ~LET %要請 の`現在の~URL$rq ◎ Let url be request’s current URL.
- ~IF[ %~url の`~scheme$urlは`~HTTP_S~scheme$である ]~AND[ %~url の`~port$urlは`不良~port$である ] ⇒ ~RET `阻止される^i ◎ If url’s scheme is an HTTP(S) scheme and url’s port is a bad port, then return blocked.
- ~RET `許容される^i ◎ Return allowed.
次の表の一列目に挙げられる`~port$urlは、 `不良~port@ であるとされる: ◎ A port is a bad port if it is listed in the first column of the following table.
~port | 代表的な~service |
---|---|
1 | tcpmux |
7 | echo |
9 | discard |
11 | systat |
13 | daytime |
15 | netstat |
17 | qotd |
19 | chargen |
20 | ftp-data |
21 | ftp |
22 | ssh |
23 | telnet |
25 | smtp |
37 | time |
42 | name |
43 | nicname |
53 | domain |
77 | — |
79 | finger |
87 | — |
95 | supdup |
101 | hostname |
102 | iso-tsap |
103 | gppitnp |
104 | acr-nema |
109 | pop2 |
110 | pop3 |
111 | sunrpc |
113 | auth |
115 | sftp |
117 | uucp-path |
119 | nntp |
123 | ntp |
135 | epmap |
139 | netbios-ssn |
143 | imap |
179 | bgp |
389 | ldap |
427 | svrloc |
465 | submissions |
512 | exec |
513 | login |
514 | shell |
515 | printer |
526 | tempo |
530 | courier |
531 | chat |
532 | netnews |
540 | uucp |
548 | afp |
556 | remotefs |
563 | nntps |
587 | submission |
601 | syslog-conn |
636 | ldaps |
993 | imaps |
995 | pop3s |
2049 | nfs |
3659 | apple-sasl |
4045 | npp |
5060 | sip |
5061 | sips |
6000 | x11 |
6665 | ircu |
6666 | ircu |
6667 | ircu |
6668 | ircu |
6669 | ircu |
6697 | ircs-u |
2.9. %要請 に対する %応答 は,~MIME型に因り阻止されるべきか?
次の手続きを走らす: ◎ Run these steps:
- %~MIME型 ~LET `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ Let mimeType be the result of extracting a MIME type from response’s header list.
-
~RET[ 次がすべて満たされるならば `阻止される^i / ~ELSE_ `許容される^i ]:
- %~MIME型 ~NEQ `失敗^i
- %要請 の`行先$rqは`~scriptに類する$
- [ %~MIME型 の`~essence$の頭部は[ `audio/^l, `image/^l, `video/^l ]いずれかに合致する ]~OR[ %~MIME型 の`~essence$ ~EQ `text/csv^l ]
3. ~HTTP拡張
3.1. `Origin^h ~header
`Origin@h 要請`~header$は、`~fetch$ が出自にしている生成元を指示する。 ◎ The `Origin` request header indicates where a fetch originates from.
注記: `Origin$h ~headerは、 `Referer$h ~headerの`~path$url情報を露呈しない~versionである(この~header名は、本来の英語の綴り “Referrer” と異なることに注意)。 これは、`~HTTP~fetch$のうち,[ `要請$の`応答~tainting$rq ~EQ `cors^l ]の下で行われるもの, および `要請$の`~method$rqに[ `GET$hm, `HEAD$hm ]以外のものを利用するもの ]すべてに利用される。 互換性の拘束から、すべての`~fetch$に含まれることはない。 ◎ The `Origin` header is a version of the `Referer` [sic] header that does not reveal a path. It is used for all HTTP fetches whose request’s response tainting is "cors", as well as those where request’s method is neither `GET` nor `HEAD`. Due to compatibility constraints it is not included in all fetches.
その`値$hd用の`~ABNF$は: ◎ Its value ABNF:
Origin = origin-or-null
origin-or-null = origin / `%s^"null" ; 文字大小区別
origin = `~scheme$url "://" `~host$url [ ":" `~port$url ]
注記: これは `ORIGIN$r による `Origin^h `~header$を置き換える。 【値に複数個の生成元を含められないようにされている。】 ◎ This supplants the `Origin` header. [ORIGIN]
`要請~Origin~headerを付加する@ ときは、所与の ( `要請$ %要請 ) に対し,次の手続きを走らす: ◎ To append a request `Origin` header, given a request request, run these steps:
- %直列化した生成元 ~LET `要請の生成元を~byte直列化する$( %要請 ) ◎ Let serializedOrigin be the result of byte-serializing a request origin with request.
- ~IF[ %要請 の`応答~tainting$rq ~EQ `cors^l ]~OR[ %要請 の`~mode$rq ~EQ `websocket^l ] ⇒# %要請 の`~header~list$rqに`~headerを付加する$( `Origin^h / %直列化した生成元 ); ~RET ◎ If request’s response tainting is "cors" or request’s mode is "websocket", then append `Origin`/serializedOrigin to request’s header list.
- ~IF[ %要請 の`~method$rq ~IN { `GET$hm, `HEAD$hm } ] ⇒ ~RET ◎ Otherwise, if request’s method is neither `GET` nor `HEAD`, then:
-
%要請 の`~referrer施策$rqに応じて: ◎ Switch on request’s referrer policy:
- `no-referrer^l
- %直列化した生成元 ~SET `null^bl ◎ Set serializedOrigin to `null`.
- `no-referrer-when-downgrade^l
- `strict-origin^l
- `strict-origin-when-cross-origin^l
- ~IF[ %要請 の`生成元$rqは`成分組~生成元$である ]~AND[ %要請 の`生成元$rqの`~scheme$o【! its %~scheme】 ~EQ `https^l ]~AND[ %要請 の`現在の~URL$rqの`~scheme$url【!%~scheme】 ~NEQ `https^l ] ⇒ %直列化した生成元 ~SET `null^bl ◎ If request’s origin is a tuple origin, its scheme is "https", and request’s current URL’s scheme is not "https", then set serializedOrigin to `null`.
- `same-origin^l
- ~IF[ ( %要請 の`生成元$rq, %要請 の`現在の~URL$rqの`生成元$url ) は`同一-生成元$でない ] ⇒ %直列化した生成元 ~SET `null^bl ◎ If request’s origin is not same origin with request’s current URL’s origin, then set serializedOrigin to `null`.
- その他
- 何もしない ◎ Do nothing.
- %要請 の`~header~list$rqに`~headerを付加する$( `Origin^h / %直列化した生成元 ) ◎ Append `Origin`/serializedOrigin to request’s header list.
注記: `要請$の`~referrer施策$rqは、すべての~fetchに織り込まれる — ~fetch側が明示的に自身の`生成元$を~serverと共有するよう(例えば`~CORS~protocol$の利用を介して)~opt-inしていなくとも。 ◎ A request’s referrer policy is taken into account for all fetches where the fetcher did not explicitly opt into sharing their origin with the server, e.g., via using the CORS protocol.
3.2. ~CORS~protocol
`~CORS~protocol@ は、非同一-生成元 間での応答の共有, および ~HTMLの `form$e 要素で可能なものより多用途の`~fetch$を可能にするためにある。 それは,~HTTPの上層にあり、それにより,応答は[ 自身が他の`生成元$と共有し得る ]ことを宣言できるようになる。 ◎ To allow sharing responses cross-origin and allow for more versatile fetches than possible with HTML’s form element, the CORS protocol exists. It is layered on top of HTTP and allows responses to declare they can be shared with other origins.
注記: これには、~firewallの背後(~intranet)からの応答による~data漏洩を防止するために,~opt-inの仕組みが必要になる。 加えて,`資格証$を含む`要請$にも、敏感になり得る~dataの漏洩を防止するため,~opt-inが必要になる。 ◎ It needs to be an opt-in mechanism to prevent leaking data from responses behind a firewall (intranets). Additionally, for requests including credentials it needs to be opt-in to prevent leaking potentially-sensitive data.
この節では、`~CORS~protocol$の,~server開発者に該当する部分について説明する。 ~UA側に課される要件は、 [ その新たな~HTTP~header ]の構文 を除き,`~fetch$ ~algoの一部として与えられる。 ◎ This section explains the CORS protocol as it pertains to server developers. Requirements for user agents are part of the fetch algorithm, except for the new HTTP header syntax.
3.2.1. 一般論
`~CORS~protocol$は、応答が 非同一-生成元の下でも共有し得るものになるかどうかを指示する,一連の~headerからなる。 ◎ The CORS protocol consists of a set of headers that indicates whether a response can be shared cross-origin.
[ ~HTMLの `form$e 要素で可能なものを超えるもの ]を孕む`要請$においては、[ `要請$の`現在の~URL$rqが `~CORS~protocol$を~supportする ]ことを確保する必要があるので,`~CORS予行~要請$が遂行される。 ◎ For requests that are more involved than what is possible with HTML’s form element, a CORS-preflight request is performed, to ensure request’s current URL supports the CORS protocol.
3.2.2. ~HTTP要請
`~CORS要請@ とは、 `Origin$h ~headerを含んでいる~HTTP要請である。 が、[ そのような要請が`~CORS~protocol$に関与している ]とは,依拠-可能に識別できない — この~headerは,[ `GET$hm, `HEAD$hm ]以外の`~method$rqを用いる どの`要請$にも含められるので。 ◎ A CORS request is an HTTP request that includes an `Origin` header. It cannot be reliably identified as participating in the CORS protocol as the `Origin` header is also included for all requests whose method is neither `GET` nor `HEAD`.
`~CORS予行~要請@ とは、`~CORS~protocol$が解されるかどうか検査するための`~CORS要請$である。 それは、`~method$に `OPTIONS$hm を利用し,次の`~header$を中に含む: ◎ A CORS-preflight request is a CORS request that checks to see if the CORS protocol is understood. It uses `OPTIONS` as method and includes these headers:
- `Access-Control-Request-Method@h
- 同じ資源に対する今後の`~CORS要請$に利用され得る 【要請~側が希望する】 `~method$を指示する。 ◎ Indicates which method a future CORS request to the same resource might use.
- `Access-Control-Request-Headers@h
- 同じ資源に対する今後の`~CORS要請$に利用され得る 【要請~側が希望する】 `~header$を指示する。 ◎ Indicates which headers a future CORS request to the same resource might use.
3.2.3. ~HTTP応答
`~CORS要請$に対する~HTTP応答には、次の`~header$を含ませれる: ◎ An HTTP response to a CORS request can include the following headers:
- `Access-Control-Allow-Origin@h
- 応答に次のどれを返すかを介して,応答が共有し得るものになるかどうかを指示する ⇒# `Origin$h 要請`~header$の~literal`値$hd( `null^bl もとり得る), `*^bl ◎ Indicates whether the response can be shared, via returning the literal value of the `Origin` request header (which can be `null`) or `*` in a response.
- `Access-Control-Allow-Credentials@h
- `要請$の`資格証~mode$rq が `include^l であるときに,応答が共有し得るものになるかどうかを指示する。 ◎ Indicates whether the response can be shared when request’s credentials mode is "include".
- 注記: `要請$の`資格証~mode$rqは、 `~CORS予行~要請$の際には常に `same-origin^l になる — すなわち,資格証を除外する — が,後続の`~CORS要請$では そうでないこともある。 したがって、`~CORS予行~要請$に対する~HTTP応答の中でも,~supportの有無が指示される必要がある。 ◎ For a CORS-preflight request, request’s credentials mode is always "same-origin", i.e., it excludes credentials, but for any subsequent CORS requests it might not be. Support therefore needs to be indicated as part of the HTTP response to the CORS-preflight request as well.
`~CORS予行~要請$に対する~HTTP応答には、次の`~header$を含ませれる: ◎ An HTTP response to a CORS-preflight request can include the following headers:
- `Access-Control-Allow-Methods@h
- `~CORS~protocol$の目的において,`応答$の`~URL$rsが~supportする`~method$を指示する。 ◎ Indicates which methods are supported by the response’s URL for the purposes of the CORS protocol.
- 注記: `Allow$h `~header$は`~CORS~protocol$の目的には関連しない。 ◎ The `Allow` header is not relevant for the purposes of the CORS protocol.
- `Access-Control-Allow-Headers@h
- `~CORS~protocol$の目的において,`応答$の`~URL$rsが~supportする`~header$を指示する。 ◎ Indicates which headers are supported by the response’s URL for the purposes of the CORS protocol.
- `Access-Control-Max-Age@h
- [ `Access-Control-Allow-Methods$h / `Access-Control-Allow-Headers$h ]`~header$から供される情報を~cacheできる期間 【~UA側が~cache内に保持してもよい最長の期間】 を秒数(既定は 5 )で指示する。 ◎ Indicates the number of seconds (5 by default) the information provided by the `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` headers can be cached.
`~CORS予行~要請$でない`~CORS要請$に対する~HTTP応答には、次の`~header$を含ませれる: ◎ An HTTP response to a CORS request that is not a CORS-preflight request can also include the following header:
- `Access-Control-Expose-Headers@h
- 応答の一部として公開できる 【~UA側の~script~APIに公開-を許可する】 `~header$を,`名前$hdの~listにより指示する。 ◎ Indicates which headers can be exposed as part of the response by listing their names.
`~CORS~protocol$に関与したいと望まない~serverは、この節に挙げた`~header$を[ `~CORS要請$ / `~CORS予行~要請$ ]に対する~HTTP応答に含ませてはナラナイ。 ~serverには、そのような~HTTP応答に `403$st `状態s$を利用することが奨励される。 ◎ In case a server does not wish to participate in the CORS protocol, its HTTP response to the CORS or CORS-preflight request must not include any of the above headers. The server is encouraged to use the 403 status in such HTTP responses.
3.2.4. [ 新たな~HTTP~header ]の構文
`~CORS~protocol$に利用される`~header$の`値$hd用の`~ABNF$は: ◎ ABNF for the values of the headers used by the CORS protocol:
Access-Control-Request-Method = `method$p
Access-Control-Request-Headers = 1#`field-name$p
wildcard = "*"
Access-Control-Allow-Origin = origin-or-null / wildcard
Access-Control-Allow-Credentials = `%s^"true" ; 文字大小区別
Access-Control-Expose-Headers = #`field-name$p
Access-Control-Max-Age = `delta-seconds$p
Access-Control-Allow-Methods = #`method$p
Access-Control-Allow-Headers = #`field-name$p
注記: [ `Access-Control-Expose-Headers^h / `Access-Control-Allow-Methods^h / `Access-Control-Allow-Headers^h ]応答`~header$用の`値$hd `*^blは、[ `資格証$を伴わない`要請$ ]に対しては,~wildcardとみなされる。 そのような`要請$に対しては、値 `*^bl をとる[ `~header$の`名前$hd / `~method$ ]のみに合致させる仕方はない。 ◎ For `Access-Control-Expose-Headers`, `Access-Control-Allow-Methods`, and `Access-Control-Allow-Headers` response headers the value `*` counts as a wildcard for requests without credentials. For such requests there is no way to solely match a header name or method that is `*`.
3.2.5. ~CORS~protocolと資格証
【! non-normative】[ `要請$の`資格証~mode$rq ~EQ `include^l ]のときには、`~fetching$の際に`資格証$を含ませること以外にも,`~CORS~protocol$の~~働きに影響iがある。 ◎ When request’s credentials mode is "include" it has an impact on the functioning of the CORS protocol other than including credentials in the fetch.
昔から、 `XMLHttpRequest$I を利用して,`要請$の`資格証~mode$rqを `include^l に設定できていたが: ◎ In the old days, XMLHttpRequest could be used to set request’s credentials mode to "include":
var %client = new XMLHttpRequest() %client.open("GET", "./") %client.withCredentials = true /* … */
今では次で足りる:
fetch("./", { credentials:"include" }).then(/* … */)◎ Nowadays, fetch("./", { credentials:"include" }).then(/* … */) suffices.
`要請$の`資格証~mode$rqが~serverから観測-可能になることは、必要とされない。 `要請$に`資格証$が存在するときに限り、そのことから観測できる。 そうであっても、`~CORS予行~要請$が`資格証$を含むことは,決してないことに注意。 ◎ A request’s credentials mode is not necessarily observable on the server; only when credentials exist for a request can it be observed by virtue of the credentials being included. Note that even so, a CORS-preflight request never includes credentials.
したがって~server開発者は、[ `資格証$で “染められた( `tainted^en )” 応答を,共有させれるかどうか ]を裁定する必要がある。 また、[ `~CORS予行~要請$を要している`要請$に,`資格証$を含めれるかどうか ]も裁定する必要がある。 一般的に言えば,[ 応答を共有させる / `資格証$を伴う要請を許容する ]ことは安全でなくする方へ~~働くので、慎重に事を~~運んで, confused deputy problem (混乱した使節の~~問題)を避ける必要がある。 ◎ The server developer therefore needs to decide whether or not responses "tainted" with credentials can be shared. And also needs to decide if requests necessitating a CORS-preflight request can include credentials. Generally speaking, both sharing responses and allowing requests with credentials is rather unsafe, and extreme care has to be taken to avoid the confused deputy problem.
`資格証$を伴う応答を共有させるためには、[ `Access-Control-Allow-Origin$h, `Access-Control-Allow-Credentials$h ]`~header$が重要になる。 次の表に、 `https://rabbit.invalid/^s へ向けた要請~用の種々の[ 合法である/合法でない ]組合nを~~説明する: ◎ To share responses with credentials, the `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` headers are important. The following table serves to illustrate the various legal and illegal combinations for a request to https://rabbit.invalid/:
要請の`資格証~mode$rq ◎ Request’s credentials mode |
`Access-Control-Allow-Origin$h
|
`Access-Control-Allow-Credentials$h
| 共有される? ◎ Shared? | 備考 ◎ Notes |
---|---|---|---|---|
`omit^l | `*^bl | なし | ✅ | — |
`omit^l | `*^bl | `true^bl | ✅ | 資格証~mode ~NEQ `include^l の場合、 `Access-Control-Allow-Credentials$h は無視される。 ◎ If credentials mode is not "include", then `Access-Control-Allow-Credentials` is ignored. |
`omit^l | `https://rabbit.invalid/^bl | なし | ❌ | `生成元を直列化-$した結果の末尾は、~slashではない。 ◎ A serialized origin has no trailing slash. |
`omit^l | `https://rabbit.invalid^bl | なし | ✅ | — |
`include^l | `*^bl | `true^bl | ❌ | 資格証~mode ~EQ `include^l の場合、 `Access-Control-Allow-Origin$h は `*^bl にできない。 ◎ If credentials mode is "include", then `Access-Control-Allow-Origin` cannot be `*`. |
`include^l | `https://rabbit.invalid^bl | `true^bl | ✅ | — |
`include^l | `https://rabbit.invalid^bl | `True^bl | ❌ | `true^bl は(~byte)文字大小区別。 ◎ `true` is (byte) case-sensitive. |
同様に、応答~header[ `Access-Control-Expose-Headers$h / `Access-Control-Allow-Methods$h / `Access-Control-Allow-Headers$h ]の値として `*^bl を利用できるのは、[ `要請$の`資格証~mode$rq ~NEQ `include^l ]のときに限られる。 ◎ Similarly, `Access-Control-Expose-Headers`, `Access-Control-Allow-Methods`, and `Access-Control-Allow-Headers` response headers can only use `*` as value when request’s credentials mode is not "include".
3.2.6. 例
`https://foo.invalid/^s にある~scriptは、 `https://bar.invalid/^s から,何か~dataを~fetchしたいと求めているとする(`資格証$も応答~headerへの~accessも重要でないとする): ◎ A script at https://foo.invalid/ wants to fetch some data from https://bar.invalid/. (Neither credentials nor response header access is important.)
var %url = "https://bar.invalid/api?key=\ 730d67a37d7f3d802e96396d00280768773813fbe726d116944d814422fc1a45\ &data=about:unicorn"; fetch(%url).then(%success, %failure)
`foo.invalid^s の開発者からはまったく透過的になるが、これには,`~CORS~protocol$が利用される — ~UAは、`~CORS~protocol$の一環として,要請~内に `Origin$h ~headerを含ませることになる: ◎ This will use the CORS protocol, though this is entirely transparent to the developer from foo.invalid. As part of the CORS protocol, the user agent will include the `Origin` header in the request:
Origin: https://foo.invalid
~UAは、 `bar.invalid^s からの応答の受信-時に, `Access-Control-Allow-Origin$h 応答~headerを検証yすることになる。 その値が[ `https://foo.invalid^bl, `*^bl ]のいずれかならば, %success ~callbackが呼出され、 他の値, あるいは~headerがない場合には, %failure ~callbackが呼出されることになる。 ◎ Upon receiving a response from bar.invalid, the user agent will verify the `Access-Control-Allow-Origin` response header. If its value is either `https://foo.invalid` or `*`, the user agent will invoke the success callback. If it has any other value, or is missing, the user agent will invoke the failure callback.
`foo.invalid^s の開発者が,今度は、応答~headerにも~accessしつつ, `bar.invalid^s から何か~dataを~fetchしようと求めたとする: ◎ The developer of foo.invalid is back, and now wants to fetch some data from bar.invalid while also accessing a response header.
fetch(%url).then(%response => { var %hsts = %response.headers.get("strict-transport-security"), %csp = %response.headers.get("content-security-policy") log(%hsts, %csp) })
`bar.invalid^s は、先の例と同じく,正しい `Access-Control-Allow-Origin$h 応答~headerを供したとする。 %hsts, %csp の値は、 `Access-Control-Expose-Headers$h 応答~headerに依存することになる。 例えば、応答に次の~headerが含まれていたとする: ◎ bar.invalid provides a correct `Access-Control-Allow-Origin` response header per the earlier example. The values of hsts and csp will depend on the `Access-Control-Expose-Headers` response header. For example, if the response included the following headers
`Content-Security-Policy$: `default-src$dir 'self' Strict-Transport-Security: max-age=31536000; includeSubdomains; preload Access-Control-Expose-Headers: Content-Security-Policy
この場合,応答が両~headerとも含んでいようが、 %hsts は ~NULL になり, %csp は `default-src 'self'^l になる。 何故なら, `bar.invalid^s は、[ `Access-Control-Expose-Headers$h 応答~header内にそれらの~header名を~listする ]ことにより,各~headerごとに明示的に共有させる必要があるので。 ◎ then hsts would be null and csp would be "default-src 'self'", even though the response did include both headers. This is because bar.invalid needs to explicitly share each header by listing their names in the `Access-Control-Expose-Headers` response header.
別法として, `bar.invalid^s は、[ `資格証$を含まない要請に対し,自身による応答~headerすべてを共有させたい ]と求めるなら, `Access-Control-Expose-Headers$h 応答~headerの値に `*^bl を利用することもできる。 `資格証$を含む要請に対しては、応答~header名は明示的に~listされる必要があり, `*^bl は利用できない。 ◎ Alternatively, if bar.invalid wanted to share all its response headers, for requests that do not include credentials, it could use `*` as value for the `Access-Control-Expose-Headers` response header. If the request would have included credentials, the response header names would have to be listed explicitly and `*` could not be used.
`foo.invalid^s の開発者が今度は、`資格証$も含ませつつ, `bar.invalid^s から何か~dataを~fetchしようとしたとする。 `資格証$には明示的な~opt-inが要求されるので、もはや開発者にとっては, `~CORS~protocol$周りで透過的でなくなる: ◎ The developer of foo.invalid returns, now fetching some data from bar.invalid while including credentials. This time around the CORS protocol is no longer transparent to the developer as credentials require an explicit opt-in:
fetch(%url, { credentials:"include" }).then(%success, %failure)
これもまた、 `bar.invalid^s が含ませた `Set-Cookie$h 応答~headerを,全部的に~~機能させる(さもなければ無視される)。 ◎ This also makes any `Set-Cookie` response headers bar.invalid includes fully functional (they are ignored otherwise).
~UAは、関連な`資格証$があれば,それも要請~内に必ず含めるようにする。 また、応答にも,より厳密な要件を課す — `bar.invalid^s からの応答には、 `Access-Control-Allow-Origin$h ~header用に `https://foo.invalid^bl を~listする必要があることに加え(`資格証$が孕まれる下では `*^bl は許容されない), `Access-Control-Allow-Credentials$h ~headerも在る必要がある: ◎ The user agent will make sure to include any relevant credentials in the request. It will also put stricter requirements on the response. Not only will bar.invalid need to list `https://foo.invalid` as value for the `Access-Control-Allow-Origin` header (`*` is not allowed when credentials are involved), the `Access-Control-Allow-Credentials` header has to be present too:
Access-Control-Allow-Origin: https://foo.invalid Access-Control-Allow-Credentials: true
応答が これらの値を伴うこれら 2 つの~headerを含んでいない場合, %failure ~callbackが呼出される。 しかしながら、 `Set-Cookie$h 応答~headerは尊重されることになる。 ◎ If the response does not include those two headers with those values, the failure callback will be invoked. However, any `Set-Cookie` response headers will be respected.
3.2.7. ~CORS~protocolの例外
仕様は、~CORS安全とされる~headerに対する制限付きな例外を,安全とされていない[ `Content-Type$h の~header値 ]用に許容していた。 そのような例外は、[ ~web内容が誘発し得るが,~web内容が制御できるのは必要最小限な[ ~headerと本体 ]に限られるような要請 ]用に~~策定された。 したがって,~serverは、[ 非同一-生成元に属する~web内容には,[ 次に挙げる[ 安全とされていない `Content-Type$h ~header値 ]を伴う,予行なしの要請 ]を誘発することが許容される ]ものと予期するベキである: ◎ Specifications have allowed limited exceptions to the CORS safelist for non-safelisted `Content-Type` header values. These exceptions are made for requests that can be triggered by web content but whose headers and bodies can be only minimally controlled by the web content. Therefore, servers should expect cross-origin web content to be allowed to trigger non-preflighted requests with the following non-safelisted `Content-Type` header values:
- `application/csp-report^bl `CSP$r
- `application/expect-ct-report+json^bl `EXPECT-CT$r
- `application/xss-auditor-report^bl
- `application/ocsp-request^bl `OCSP$r
仕様は、新たな例外を導入するのは避けるベキである — そうする場合、~security上の帰結を注意深く考慮するベキである。 新たな例外は、 課題を申請して 提案できる。 ◎ Specifications should avoid introducing new exceptions and should only do so with careful consideration for the security consequences. New exceptions can be proposed by filing an issue.
3.3. `Content-Type^h ~header
`Content-Type$h ~headerは,大部分は~HTTPにて定義されているが、その処理~modelは,ここに定義される — ~HTTPが定義する~ABNFは、~web内容と互換でないので。 `HTTP$r ◎ The `Content-Type` header is largely defined in HTTP. Its processing model is defined here as the ABNF defined in HTTP is not compatible with web content. [HTTP]
`~header~listから~MIME型を抽出する@ ときは、所与の ( `~header~list$ %~headerたち ) に対し,次を走らす: ◎ To extract a MIME type from a header list headers, run these steps:
- %~charset ~LET ~NULL ◎ Let charset be null.
- %~essence ~LET ~NULL ◎ Let essence be null.
- %~MIME型 ~LET ~NULL ◎ Let mimeType be null.
- %値~list ~LET `~header~listから値を取得して復号して分割する$( %~headerたち, `Content-Type$h ) ◎ Let values be the result of getting, decoding, and splitting `Content-Type` from headers.
- ~IF[ %値~list ~EQ ~NULL ] ⇒ ~RET `失敗^i ◎ If values is null, then return failure.
-
%値~list を成す ~EACH( %値 ) に対し: ◎ For each value of values:
- %一時的~MIME型 ~LET `~MIME型を構文解析する$( %値 ) ◎ Let temporaryMimeType be the result of parsing value.
- ~IF[ %一時的~MIME型 ~EQ `失敗^i ]~OR[ %一時的~MIME型 の`~essence$ ~EQ `*/*^l ] ⇒ ~CONTINUE ◎ If temporaryMimeType is failure or its essence is "*/*", then continue.
- %~MIME型 ~SET %一時的~MIME型 ◎ Set mimeType to temporaryMimeType.
- %~parameters ~LET %~MIME型 の`~parameters$ ◎ ↓
-
~IF[ %~MIME型 の`~essence$ ~NEQ %~essence ]: ◎ If mimeType’s essence is not essence, then:
- %~charset ~SET ~NULL ◎ Set charset to null.
- ~IF[ %~parameters[ `charset^l ] ~NEQ ε ] ⇒ %~charset ~SET %~parameters[ `charset^l ] ◎ If mimeType’s parameters["charset"] exists, then set charset to mimeType’s parameters["charset"].
- %~essence ~SET %~MIME型 の`~essence$ ◎ Set essence to mimeType’s essence.
- ~ELIF[ %~parameters[ `charset^l ] ~EQ ε ]~AND[ %~charset ~NEQ ~NULL ] ⇒ %~parameters[ `charset^l ] ~SET %~charset ◎ Otherwise, if mimeType’s parameters["charset"] does not exist, and charset is non-null, set mimeType’s parameters["charset"] to charset.
- ~IF[ %~MIME型 ~EQ ~NULL ] ⇒ ~RET `失敗^i ◎ If mimeType is null, then return failure.
- ~RET %~MIME型 ◎ Return mimeType.
`~header~listから~MIME型を抽出する$ が返す結果が[ `失敗^i / 所与の内容形式~用に不正な`~essence$を持つ`~MIME型$ ]である場合、致命的な~errorとして扱う。 既存の~web~platform特能は、この~patternに常に従ってはいなかった — それは、長年にわたり,それらの特能における~security脆弱性の大多数の源であった。 対照的に,`~MIME型$の`~parameters$は、概して安全に無視できる。 ◎ When extract a MIME type returns failure or a MIME type whose essence is incorrect for a given format, treat this as a fatal error. Existing web platform features have not always followed this pattern, which has been a major source of security vulnerabilities in those features over the years. In contrast, a MIME type’s parameters can typically be safely ignored.
`~header~listから~MIME型を抽出する$ が、実施においてどう機能するかを次に示す: ◎ This is how extract a MIME type functions in practice:
(~network上の)~header列 ◎ Headers (as on the network) | (直列化された)出力 ◎ Output (serialized) |
---|---|
Content-Type: text/plain;charset=gbk, text/html | `text/html^c |
Content-Type: text/html;charset=gbk;a=b, text/html;x=y | `text/html;x=y;charset=gbk^c |
Content-Type: text/html;charset=gbk;a=b Content-Type: text/html;x=y | |
Content-Type: text/html;charset=gbk Content-Type: x/x Content-Type: text/html;x=y | `text/html;x=y^c |
Content-Type: text/html Content-Type: cannot-parse | `text/html^c |
Content-Type: text/html Content-Type: */* | |
Content-Type: text/html Content-Type: |
3.4. `X-Content-Type-Options^h ~header
`X-Content-Type-Options@h 応答`~header$を利用して、[ `応答$の `Content-Type$h `~header$を`要請$の`行先$rqと突き合わせて検査する ]ことを要求できる。 ◎ The `X-Content-Type-Options` response header can be used to require checking of a response’s `Content-Type` header against the destination of a request.
`~nosniffかどうか決定する@ ときは、所与の ( `~header~list$ %~list ) に対し,次を走らす: ◎ To determine nosniff, given a header list list, run these steps:
- %値たち ~LET `~header~listから値を取得して復号して分割する$( %~list, `X-Content-Type-Options$h ) ◎ Let values be the result of getting, decoding, and splitting `X-Content-Type-Options` from list.
- ~IF[ %値たち ~EQ ~NULL ] ⇒ ~RET ~F ◎ If values is null, then return false.
- ~IF[ %値たち[ 0 ] は `nosniff^l に`~ASCII大小無視$で合致する ] ⇒ ~RET ~T ◎ If values[0] is an ASCII case-insensitive match for "nosniff", then return true.
- ~RET ~F ◎ Return false.
[ ~web開発者/適合性~検査器 ]は、 `X-Content-Type-Options$h 用の`値$hdに,次の`~ABNF$を利用しなければナラナイ: ◎ Web developers and conformance checkers must use the following value ABNF for `X-Content-Type-Options`:
X-Content-Type-Options = "nosniff" ; 大小無視
3.4.1. %要請 に対する %応答 は,~nosniffに因り阻止されるべきか?
次の手続きを走らす: ◎ Run these steps:
- ~IF[ `~nosniffかどうか決定する$( %応答 の`~header~list$rs ) ~EQ ~F ] ⇒ ~RET `許容される^i ◎ If determine nosniff with response’s header list is false, then return allowed.
- %~MIME型 ~LET `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ Let mimeType be the result of extracting a MIME type from response’s header list.
- %行先 ~LET %要請 の`行先$rq ◎ Let destination be request’s destination.
-
~RET[ 次のいずれかが満たされるならば `阻止される^i / ~ELSE_ `許容される^i ] ⇒
- [ %行先 は`~scriptに類する$ ]~AND[[ %~MIME型 ~EQ `失敗^i ]~OR[ %~MIME型 は`~JS~MIME型$でない ]]
- [ %行先 ~EQ `style^l ]~AND[[ %~MIME型 ~EQ `失敗^i ]~OR[ %~MIME型 の`~essence$ ~NEQ `text/css^l ]]
注記: ここで考慮される`要請$の`行先$rqは、`~scriptに類する$ものか `style^l に限られる — どの悪用も これらに該当するので。 また、ここで `image^l も考慮すると,配備-済みの内容と互換にならなくなる。 ◎ Only request destinations that are script-like or "style" are considered as any exploits pertain to them. Also, considering "image" was not compatible with deployed content.
3.5. ~CORB
注記: ~CORBとも~~略称される,非同一-生成元からの読取nの阻止-法( `Cross-Origin Read Blocking^en )は、疑わしい非同一-生成元~資源~fetchを識別する~algoであり(例: `img^e 要素の内側で~JSONを具現化しようと試みる様な~fetchは、どうやっても失敗することになる),そのような資源が~web~pageに達する前に阻止する。 ~CORBは、敏感な~dataを非同一-生成元~web~pageから離れた所に保って,それが漏洩する~riskを抑制する。 ◎ Cross-origin read blocking, better known as CORB, is an algorithm which identifies dubious cross-origin resource fetches (e.g., fetches that would fail anyway like attempts to render JSON inside an img element) and blocks them before they reach a web page. CORB reduces the risk of leaking sensitive data by keeping it further from cross-origin web pages.
次に挙げるものが, `~CORBで保護される~MIME型@ とされる ⇒# `~HTML~MIME型$, `~JSON~MIME型$, `image/svg+xml^bl 以外の`~XML~MIME型$ ◎ A CORB-protected MIME type is an HTML MIME type, a JSON MIME type, or an XML MIME type excluding image/svg+xml.
注記: ~CORBがなくとも,[ `~CORBで保護される~MIME型$を伴う非同一-生成元~資源 ]を成す内容に~accessすることは、次のいずれかになる:
- `~CORS~protocol$により管理される(例: `XMLHttpRequest$I の事例)
- 観測-可能にならない(例:~pingや~CSP報告の事例など,応答を無視するもの)
- ~errorになる(例: `img^e 要素~内に埋込まれた~HTML文書を画像として復号するのに失敗したとき)
すなわち,~CORBは、~web~pageを妨害することなく,`~CORBで保護される~MIME型$の資源を阻止できる。
◎ Even without CORB, accessing the content of cross-origin resources with CORB-protected MIME types is either managed by the CORS protocol (e.g., in case of XMLHttpRequest), not observable (e.g., in case of pings or CSP reports which ignore the response), or would result in an error (e.g., when failing to decode an HTML document embedded in an img element as an image). This means that CORB can block CORB-protected MIME types resources without being disruptive to web pages.`~CORB検査@ を遂行するときは、所与の ( %要請, %応答 ) に対し,次を走らす: ◎ To perform a CORB check, given a request and response, run these steps:
-
~IF[ %要請 の`起動元$rq ~EQ `download^l ] ⇒ ~RET `許容される^i ◎ If request’s initiator is "download", then return allowed.
~download法を~naviの一種に~~落とし込めば、この段は除去できる。 ◎ If we recast downloading as navigation this step can be removed.
- ~IF[ %要請 の`現在の~URL$rqの`~scheme$urlは`~HTTP_S~scheme$でない ] ⇒ ~RET `許容される^i ◎ If request’s current URL’s scheme is not an HTTP(S) scheme, then return allowed.
- %~MIME型 ~LET `~header~listから~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ Let mimeType be the result of extracting a MIME type from response’s header list.
- ~IF[ %~MIME型 ~EQ `失敗^i ] ⇒ ~RET `許容される^i ◎ If mimeType is failure, then return allowed.
- ~IF[ %応答 の`状態s$rs ~EQ `206$st ]~AND[ %~MIME型 は`~CORBで保護される~MIME型$である ] ⇒ ~RET `阻止される^i ◎ If response’s status is 206 and mimeType is a CORB-protected MIME type, then return blocked.
-
~IF[ `~nosniffかどうか決定する$( %応答 の`~header~list$rs ) ~EQ ~T ]~AND[[ %~MIME型 は`~CORBで保護される~MIME型$である ]~OR[ %~MIME型 の`~essence$ ~EQ `text/plain^l ]] ⇒ ~RET `阻止される^i ◎ If determine nosniff with response’s header list is true and mimeType is a CORB-protected MIME type or its essence is "text/plain", then return blocked.
注記: ~CORBが保護する `text/plain^bl 応答は、 `X-Content-Type-Options: nosniff^bl ~headerを伴うものに限られる。 あいにく,[ その~headerを伴わない, `状態s$rs `206$st の応答 ]を保護することは、あまりに多くの[ `~MIME型$に `text/plain^bl を伴う,既存の動画~応答 ]を壊すことになる。 ◎ CORB only protects text/plain responses with a `X-Content-Type-Options: nosniff` header. Unfortunately, protecting such responses without that header when their status is 206 would break too many existing video responses that have a text/plain MIME type.
- ~RET `許容される^i ◎ Return allowed.
3.6. `Cross-Origin-Resource-Policy^h ~header
`Cross-Origin-Resource-Policy@h 応答`~header$は、次を要求するために利用できる ⇒ [ `要請$の`~mode$rq ~EQ `no-cors^l ]のときには、`要請$の`現在の~URL$rqの`生成元$urlを`要請$の`生成元$rqと突き合わせて検査する ◎ The `Cross-Origin-Resource-Policy` response header can be used to require checking a request’s current URL’s origin against a request’s origin when request’s mode is "no-cors".
その`値$hd用の`~ABNF$は: ◎ Its value ABNF:
Cross-Origin-Resource-Policy
= `%s^"same-origin" / `%s^"same-site" / `%s^"cross-origin"; 文字大小区別
【 ~CORPは、[ 非同一-生成元~資源~施策/この~header名 ]の略称を表す。 】
`非同一-生成元~資源~施策~検査@ を遂行するときは、所与の ( `生成元$【!`生成元$url】 %生成元, `環境~設定群~obj$ %設定群~obj, 文字列 %行先, `応答$ %応答, 真偽値 %~navi用 (省略時は ~F )) に対し,次の手続きを走らす: ◎ To perform a cross-origin resource policy check, given an origin origin, an environment settings object settingsObject, a string destination, a response response, and an optional boolean forNavigation, run these steps: • Set forNavigation to false if it is not given.
- %埋込元~施策 ~LET %設定群~obj の`埋込元~施策$enV ◎ Let embedderPolicy be settingsObject’s embedder policy.
-
~IF[ `非同一-生成元~資源~施策~内部~検査$( %生成元, `unsafe-none$l, %応答, %~navi用 ) ~EQ `阻止される^i ] ⇒ ~RET `阻止される^i ◎ If the cross-origin resource policy internal check with origin, "unsafe-none", response, and forNavigation returns blocked, then return blocked.
注記: この段が必要になるのは、下に与える非同一-生成元~埋込元~施策に関係しない違反は,報告するよう求まれないからである。 ◎ This step is needed because we don’t want to report violations not related to Cross-Origin Embedder Policy below.
- ~IF[ `非同一-生成元~資源~施策~内部~検査$( %生成元 , %埋込元~施策 の`報告のみの値$embP, %応答, %~navi用 ) ~EQ `阻止される^i ] ⇒ `非同一-生成元~埋込元~施策~CORP違反~報告を~queueする$( %応答, %設定群~obj, %行先, ~T ) ◎ If the cross-origin resource policy internal check with origin, embedderPolicy’s report only value, response, and forNavigation returns blocked, then queue a cross-origin embedder policy CORP violation report with response, settingsObject, destination, and true.
- ~IF[ `非同一-生成元~資源~施策~内部~検査$( %生成元, %埋込元~施策 の`値$embP, %応答, %~navi用 ) ~EQ `許容される^i ] ⇒ ~RET `許容される^i ◎ If the cross-origin resource policy internal check with origin, embedderPolicy’s value, response, and forNavigation returns allowed, then return allowed.
- `非同一-生成元~埋込元~施策~CORP違反~報告を~queueする$( %応答, %設定群~obj, %行先, ~F ) ◎ Queue a cross-origin embedder policy CORP violation report with response, settingsObject, destination, and false.
- ~RET `阻止される^i ◎ Return blocked.
注記: ~HTMLの`~navigate~algo$に限り,この検査を %~navi用 に ~T を与える下で利用する — それはまた、この検査を,常に入子な【閲覧文脈に対する】~navi用に利用する。 他の場合、 %応答 は[ `不透明な絞込み応答$の`内部~応答$か,そうなるもの ]になる。 `HTML$r ◎ Only HTML’s navigate algorithm uses this check with forNavigation set to true, and it’s always for nested navigations. Otherwise, response is either the internal response of an opaque filtered response or a response which will be the internal response of an opaque filtered response. [HTML]
`非同一-生成元~資源~施策~内部~検査@ を遂行するときは、所与の ( `生成元$【!`生成元$url】 %生成元, `埋込元~施策~値$ %埋込元~施策~値, `応答$ %応答, 真偽値 %~navi用 ) に対し,次の手続きを走らす: ◎ To perform a cross-origin resource policy internal check, given an origin origin, an embedder policy value embedderPolicyValue, a response response, and a boolean forNavigation, run these steps:
- ~IF[ %~navi用 ~EQ ~T ]~AND[ %埋込元~施策~値 ~EQ `unsafe-none$l ] ⇒ ~RET `許容される^i ◎ If forNavigation is true and embedderPolicyValue is "unsafe-none", then return allowed.
-
%施策 ~LET `~header~listから値を取得する$( %応答 の`~header~list$rs, `Cross-Origin-Resource-Policy$h ) ◎ Let policy be the result of getting `Cross-Origin-Resource-Policy` from response’s header list.
注記: `Cross-Origin-Resource-Policy: same-site, same-origin^bl にされた場合、[ %埋込元~施策~値 ~EQ `unsafe-none$l【すなわち ~NEQ `require-corp$l 】 ]である限り,以下において %施策 が何かに合致することは決してないので, `許容される^i を返すことになる。 `Cross-Origin-Resource-Policy$h ~headerが複数個ある場合も同じ効果になる。 【すなわち,`~field値$が複数個の~tokenを含む場合、~headerが無かったときと同じになる。】 ◎ This means that `Cross-Origin-Resource-Policy: same-site, same-origin` ends up as allowed below as it will never match anything, as long as embedderPolicyValue is "unsafe-none". Two or more `Cross-Origin-Resource-Policy` headers will have the same effect.
- ~IF[ %施策 ~NIN { `same-origin^bl, `same-site^bl, `cross-origin^bl } ] ⇒ %施策 ~SET ~NULL ◎ If policy is neither `same-origin`, `same-site`, nor `cross-origin`, then set policy to null.
- ~IF[ %施策 ~EQ ~NULL ]~AND[ %埋込元~施策~値 ~EQ `require-corp$l ] ⇒ %施策 ~SET `same-origin^bl ◎ If policy is null and embedderPolicyValue is "require-corp", then set policy to `same-origin`.
-
%施策 に応じて: ◎ Switch on policy:
- ~NULL
- `cross-origin^bl
- ~RET `許容される^i ◎ Return allowed.
- `same-origin^bl
- ~RET [ 次が満たされるならば `許容される^i / ~ELSE_ `阻止される^i ] ⇒ ( %生成元, %応答 の`~URL$rsの`生成元$url ) は、`同一-生成元$である ◎ If origin is same origin with response’s URL’s origin, then return allowed. ◎ Otherwise, return blocked.
- `same-site^bl
-
~RET [ 次が すべて満たされるならば `許容される^i / ~ELSE_ `阻止される^i ]:
- ( %生成元, %応答 の`~URL$rsの`生成元$url ) は、`~scheme無しで同じ~site$である
- [ %生成元 の`~scheme$url ~EQ `https^l ]~OR[ %応答 の`~URL$rsの`~scheme$url ~NEQ `https^l ]
- 注記: `Cross-Origin-Resource-Policy: same-site^bl は、要請している生成元【 %生成元 】が~secureでない場合,~secureな~transportを介して送達された応答は【条件に】合致すると見なさない — それらの~hostが~secureか否かを除けば【すなわち,~scheme無しで】同じ~siteであっても。 ~secureに~transportされた応答が合致するのは、【要請の】起動元が~secureに~transportされた場合に限られることになる。 ◎ `Cross-Origin-Resource-Policy: same-site` does not consider a response delivered via a secure transport to match a non-secure requesting origin, even if their hosts are otherwise same site. Securely-transported responses will only match a securely-transported initiator.
`非同一-生成元~埋込元~施策~CORP違反~報告を~queueする@ ときは、所与の ( `応答$ %応答, `環境~設定群~obj$ %設定群~obj, 文字列 %行先, 真偽値 %報告のみ ) に対し,次の手続きを走らす: ◎ To queue a cross-origin embedder policy CORP violation report, given a response response, an environment settings object settingsObject, a string destination, and a boolean reportOnly, run these steps:
- %施策 ~LET %設定群~obj の`埋込元~施策$enV ◎ ↓
- %報告先 ~LET %報告のみ に応じて ⇒# ~T ならば %施策 の`報告のみの報告先$embP/ ~F ならば %施策 の`報告先$embP ◎ Let endpoint be settingsObject’s embedder policy’s report only reporting endpoint if reportOnly is true and settingsObject’s embedder policy’s reporting endpoint otherwise.
- %直列化した~URL ~LET `応答~URLを報告-用に直列化する$( %応答 ) ◎ Let serializedURL be the result of serializing a response URL for reporting with response.
- %処置 ~LET %報告のみ に応じて ⇒# ~T ならば `reporting^l / ~F ならば `enforce^l ◎ Let disposition be "reporting" if reportOnly is true; otherwise "enforce".
-
%本体 ~LET 次に挙げる~propを包含している新たな~obj:
~key 値 `type^l `corp^l `blockedURL^l %直列化した~URL `destination^l %行先 `disposition^l %処置 - `報告を~queueする$( %本体, `~coep報告~種別$i, %報告先, %設定群~obj ) `REPORTING$r ◎ Queue body as the "coep" report type for endpoint on settingsObject. [REPORTING]
4. ~fetching
注記: 次の~algoが、`~fetching$を定義する。 それは,大雑把に言えば、`要請$, および[ 演算の間の様々な地点で走らす 1 個以上の~algo ]を~~入力にとる。 下に挙げる 3, 4 個目の~algoには`応答$が渡され、 1, 2 個目の~algoは~uploadを捕捉するために利用できる。 ◎ The algorithm below defines fetching. In broad strokes, it takes a request and one or more algorithms to run at various points during the operation. A response is passed to the last two algorithms listed below. The first two algorithms can be used to capture uploads.
所与の`要請$ %要請 を `~fetchする@ ときは、所与の:
- `要請の本体を処理する@V ⇒ ~NULL(省略時)/ 伝送される~byte数を表現する整数を受容する~algo
- `要請の本体の終端を処理する@V ⇒ ~NULL(省略時)/ 引数をとらない~algo
- `応答を処理する@V ⇒ ~NULL(省略時)/ `応答$を受容する~algo
- `応答の本体の終端を処理する@V ⇒ ~NULL(省略時)/[ `応答$ / ~NULL/ `失敗^i / `~byte列$ ]を受容する~algo
- `並列~queueを利用する?@V ⇒ 真偽値(省略時は ~F )
に対し,以下の手続きを走らす:
◎ To fetch, given a request request,\ an optional algorithm processRequestBody,\ an optional algorithm processRequestEndOfBody,\ an optional algorithm processResponse, an optional algorithm processResponseEndOfBody,\ and an optional boolean useParallelQueue (default false),\ run the steps below.\ If given, processRequestBody must be an algorithm accepting an integer representing the number of bytes transmitted.\ If given, processRequestEndOfBody must be an algorithm accepting no arguments.\ If given, processResponse must be an algorithm accepting a response.\ If given, processResponseEndOfBody must be an algorithm accepting a response and null, failure, or a byte sequence.- 進行中の`~fetch$は, `終了され@ ることもある。 また,各 終了には %中止~flag ~IN { `中止する^i, ε } が伴われ、指定されない限り ε とする。 【同じ~fetchに対し,複数の終了が生じた場合、どの %中止~flag が優先される?】 ◎ An ongoing fetch can be terminated with flag aborted, which is unset unless otherwise specified.
- ~UAは、進行中の~fetchを `休止-@ するよう,依頼されることもある。 ~UAは、その休止~要請を受容しても無視してもヨイ。 休止された~fetchは、 `再開-@ できる。 ~UAは、[ 進行中の~fetchが,当の要請に対する[ ~HTTP~cache内の応答 ]を更新している場合 ]には,休止~要請を無視するベキである。 ◎ The user agent may be asked to suspend the ongoing fetch. The user agent may either accept or ignore the suspension request. The suspended fetch can be resumed. The user agent should ignore the suspension request if the ongoing fetch is updating the response in the HTTP cache for the request.
注記: 次のいずれかが満たされる場合、~UAは,`要請$に対する~HTTP~cache内の~entryを更新しない:
- 要請の`~cache~mode$rq ~EQ `no-store^l
- 応答の `Cache-Control$h ~header値は `no-store^dir を含む `HTTP-CACHING$r
- %~taskの行先 ~LET ~NULL ◎ Let taskDestination be null.
- ~IF[ %並列~queueを利用する? ~EQ ~T ] ⇒ %~taskの行先 ~SET `新たな並列~queueを開始する$() ◎ If useParallelQueue is true, then set taskDestination to the result of starting a new parallel queue.
- ~ELIF[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ %~taskの行先 ~SET %要請 の`~client$rq の`大域~obj$enV ◎ Otherwise, if request’s client is non-null, set taskDestination to request’s client’s global object.
- %~fetch~params ~LET 新たな`~fetch~params$ — その ⇒# `要請$fP ~SET %要請, `要請の本体を処理する$fP ~SET %要請の本体を処理する, `要請の本体の終端を処理する$fP ~SET %要請の本体の終端を処理する, `応答を処理する$fP ~SET %応答を処理する, `応答の本体の終端を処理する$fP ~SET %応答の本体の終端を処理する, `~taskの行先$fP ~SET %~taskの行先 ◎ Let fetchParams be a new fetch params whose request is request, process request body is processRequestBody, process request end-of-body is processRequestEndOfBody, process response is processResponse, process response end-of-body is processResponseEndOfBody, and task destination is taskDestination.
- ~IF[ %要請 の`本体$rqは`~byte列$である ] ⇒ %要請 の`本体$rq ~SET 次の結果を成す`本体$ ⇒ `本体と内容~型を安全に抽出する$( %要請 の`本体$rq ) ◎ If request’s body is a byte sequence, then set request’s body to the first return value of safely extracting request’s body.
- ~IF[ %要請 の`~window$rq ~EQ `client^l ] ⇒ %要請 の`~window$rq ~SET [ 次が満たされるならば %要請 の`~client$rq / ~ELSE_ `no-window^l ] ⇒ %要請 の`~client$rqの`大域~obj$enVは `Window$I ~objである ◎ If request’s window is "client", then set request’s window to request’s client, if request’s client’s global object is a Window object; otherwise "no-window".
- ~IF[ %要請 の`生成元$rq ~EQ `client^l ] ⇒ %要請 の`生成元$rq ~SET %要請 の`~client$rqの`生成元$enV ◎ If request’s origin is "client", then set request’s origin to request’s client’s origin.
-
~IF[ %要請 の`~header~list$rq内に[ `Accept$h を`名前に持つ~header$ ]は無い ]: ◎ If request’s header list does not contain `Accept`, then:
- %値 ~LET `*/*^bl ◎ Let value be `*/*`.
-
~UAは、 %要請 の`行先$rqに応じて, %値 を次に与える値に設定するベキである: ◎ A user agent should set value to the first matching statement, if any, switching on request’s destination:
- `document^l
- `frame^l
- `iframe^l
- `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^bl
- `image^l
- `image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5^bl
- `style^l
- `text/css,*/*;q=0.1^bl
- %要請 の`~header~list$rqに`~headerを付加する$( `Accept$h / %値 ) ◎ Append `Accept`/value to request’s header list.
- ~IF[ %要請 の`~header~list$rq内に[ `Accept-Language$h を`名前に持つ~header$ ]は無い ] ⇒ ~UAは、次を行うベキである ⇒ %要請 の`~header~list$rqに`~headerを付加する$( `Accept-Language$h / 適切な`値$hd ) ◎ If request’s header list does not contain `Accept-Language`, then user agents should append `Accept-Language`/an appropriate value to request’s header list.
-
~IF[ %要請 の`優先度$rq ~EQ ~NULL ] ⇒ %要請 の`優先度$rq ~SET %要請 の[ `起動元$rq, `行先$rq ]を適切に利用して得られる,~UAにより定義される~obj ◎ If request’s priority is null, then use request’s initiator and destination appropriately in setting request’s priority to a user-agent-defined object.
注記: ~UAにより定義される~objが包摂し得るのは、次のいずれかである:
- ~HTTP2用の,~streamの[ 重みと依存関係 ]
- HTTP/1 ~fetchにおける[ ~dispatchと処理 ]に優先度を与えるために利用される,前項と等価な情報
-
~IF[ %要請 は`下位資源~要請$である ]: ◎ If request is a subresource request, then:
- %記録 ~LET 次のようにされた,新たな`~fetch記録$ ⇒# `要請$fg ~SET %要請; `~fetch$fg ~SET この`~fetch$~algoの~instance ◎ Let record be a new fetch record consisting of request and this instance of the fetch algorithm.
- [ %要請 の`~client$rqの`~fetch~group$を成す,`~fetch記録$たちの~list ]に %記録 を付加する ◎ Append record to request’s client’s fetch group list of fetch records.
- ~RET `~main~fetch$( %~fetch~params ) ◎ Run main fetch given fetchParams.
4.1. ~main~fetch
`~main~fetch@ を遂行するときは、所与の ( `~fetch~params$ %~fetch~params, 真偽値 %再帰的?(省略時は ~F ) ) に対し,次の手続きを走らす: ◎ To main fetch, given a fetch params fetchParams and an optional boolean recursive (default false), run these steps:
- %要請 ~LET %~fetch~params の`要請$fP ◎ Let request be fetchParams’s request.
- %応答 ~LET ~NULL ◎ Let response be null.
- ~IF[ %要請 の`局所~URLのみ~flag$rq ~EQ ~T ]~AND[ %要請 の`現在の~URL$rqは`局所的$でない ] ⇒ %応答 ~SET `~network~error$ ◎ If request’s local-URLs-only flag is set and request’s current URL is not local, then set response to a network error.
- %要請 に対する ~CSP違反を報告する ◎ Run report Content Security Policy violations for request.
- 適切になるなら %要請 を先天的に認証-済み~URLに昇格する `UPGRADE$r ◎ Upgrade request to a potentially secure URL, if appropriate. [UPGRADE]
-
~IF[ 次のいずれかの結果 ~EQ `阻止される^i ]…:
- %要請 の`~fetchingは,不良~portに因り阻止されるべきか?$
- %要請 の~fetchingは,混在d内容として阻止されるべきか? `MIX$r
- %要請 は,~CSPにより阻止されるべきか?
…ならば ⇒ %応答 ~SET `~network~error$
◎ If should request be blocked due to a bad port, should fetching request be blocked as mixed content, or should request be blocked by Content Security Policy returns blocked, then set response to a network error. [MIX] - ~IF[ %要請 の`~referrer施策$rq ~EQ 空~文字列 ]~AND[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ %要請 の`~referrer施策$rq ~SET %要請 の`~client$rqの`~referrer施策$enV `REFERRER$r ◎ If request’s referrer policy is the empty string and request’s client is non-null, then set request’s referrer policy to request’s client’s referrer policy. [REFERRER]
- ~IF[ %要請 の`~referrer施策$rq ~EQ 空~文字列 ] ⇒ %要請 の`~referrer施策$rq ~SET `既定の~referrer施策$ ◎ If request’s referrer policy is the empty string, then set request’s referrer policy to the default referrer policy.
-
~IF[ %要請 の`~referrer$rq ~NEQ `no-referrer^l ] ⇒ %要請 の`~referrer$rq ~SET %要請 の`~referrerを決定-$した結果 `REFERRER$r ◎ If request’s referrer is not "no-referrer", then set request’s referrer to the result of invoking determine request’s referrer. [REFERRER]
注記: `Referrer Policy^cite 仕様に言明されている様に、~UAは,末端利用者に対し, %要請 の`~referrer$rqを常に `no-referrer^l で上書きするような選択余地, または より敏感でない情報を公開するような選択余地を与えることができる。 ◎ As stated in Referrer Policy, user agents can provide the end user with options to override request’s referrer to "no-referrer" or have it expose less sensitive information.
-
~IF[ 次のいずれの条件も満たされる ]…: ◎ Set request’s current URL’s scheme to "https" if all of the following conditions are true:
- %要請 の`現在の~URL$rqの`~scheme$url ~EQ `http^l ◎ request’s current URL’s scheme is "http"
- %要請 の`現在の~URL$rqの`~host$urlは`~domain$urlである ◎ request’s current URL’s host is a domain
-
%要請 の`現在の~URL$rqの`~host$urlを Known HSTS Host Domain Name Matching `HSTS$r に従って照合した結果は、次のいずれかである:
- superdomain match with an asserted `includeSubDomains^dir directive
- congruent match (with or without an asserted `includeSubDomains^dir directive)
…ならば ⇒ %要請 の`現在の~URL$rqの`~scheme$url ~SET `https^l ◎ ↑
- ~IF[ %再帰的? ~EQ ~F ] ⇒ 以降の手続きは、`並列的$に走らす ◎ If recursive is false, then run the remaining steps in parallel.
-
~IF[ %応答 ~EQ ~NULL ] ⇒ %応答 ~SET 次の下位手続きを走らせた結果: ◎ If response is null, then set response to the result of running the steps corresponding to the first matching statement:
-
~IF[ 次のいずれかが満たされる ]…
- [ ( %要請 の`現在の~URL$rqの`生成元$, %要請 の`生成元$rq ) は`同一-生成元$である ]~AND[ %要請 の`応答~tainting$rq ~EQ `basic^l ] ◎ request’s current URL’s origin is same origin with request’s origin, and request’s response tainting is "basic"
- %要請 の`現在の~URL$rqの`~scheme$url ~EQ `data^l ◎ request’s current URL’s scheme is "data"
- %要請 の`~mode$rq ~IN { `navigate^l, `websocket^l } ◎ request’s mode is "navigate" or "websocket"
…ならば:
- %要請 の`応答~tainting$rq ~SET `basic^l ◎ Set request’s response tainting to "basic".
- ~RET `~scheme~fetch$( %~fetch~params ) ◎ Return the result of running scheme fetch given fetchParams.
注記: ~HTMLは、[ `~scheme$url ~EQ `data^l ]なる`~URL$から作成された どの[ 文書 / ~worker ]に対しても,一意かつ`不透明な生成元$をアテガう。 ~swは、[ `~scheme$url ~IN `~HTTP_S~scheme$ ]なる`~URL$からのみ作成される。 `HTML$r `SW$r ◎ HTML assigns any documents and workers created from URLs whose scheme is "data" a unique opaque origin. Service workers can only be created from URLs whose scheme is an HTTP(S) scheme. [HTML] [SW]
- ~IF[ %要請 の`~mode$rq ~EQ `same-origin^l ] ⇒ ~RET `~network~error$ ◎ request’s mode is "same-origin" • Return a network error.
-
~IF[ %要請 の`~mode$rq ~EQ `no-cors^l ]: ◎ request’s mode is "no-cors"
- ~IF[ %要請 の`~redirect~mode$rq ~NEQ `follow^l ] ⇒ ~RET `~network~error$ ◎ If request’s redirect mode is not "follow", then return a network error.
- %要請 の`応答~tainting$rq ~SET `opaque^l ◎ Set request’s response tainting to "opaque".
- %~CORSなし要請 ~LET `~scheme~fetch$( %~fetch~params ) ◎ Let noCorsResponse be the result of running scheme fetch given fetchParams.
- ~IF[ %~CORSなし要請 は`絞込み応答$である ]~OR[ `~CORB検査$( %要請, %~CORSなし要請 ) ~EQ `許容される^i ] ⇒ ~RET %~CORSなし要請 ◎ If noCorsResponse is a filtered response or the CORB check with request and noCorsResponse returns allowed, then return noCorsResponse.
-
~RET 次のようにされた新たな`応答$ ⇒# `状態s$rs ~SET %~CORSなし要請 の`状態s$rs, `~CSP~list$rs ~SET %~CORSなし要請 の`~CSP~list$rs ◎ Return a new response whose status is noCorsResponse’s status, and CSP list is noCorsResponse’s CSP list.
これが有効な防御になるのは、~side-channel攻撃に抗することに限られる — %~CORSなし要請 を当の要請を起動した~processから隔離し続けた場合に。 ◎ This is only an effective defense against side channel attacks if noCorsResponse is kept isolated from the process that initiated the request.
- ~IF[ %要請 の`現在の~URL$rqの`~scheme$urlは`~HTTP_S~scheme$でない ] ⇒ ~RET `~network~error$ ◎ request’s current URL’s scheme is not an HTTP(S) scheme • Return a network error.
-
~IF[ 次のいずれかが満たされる ]…:
- %要請 の`~CORS予行~利用~flag$rq ~EQ ~T ◎ request’s use-CORS-preflight flag is set
- [ %要請 の`非安全~要請~flag$rq ~EQ ~T ]~AND[[ %要請 の`~method$rqは `~CORS安全とされる~method$でない ]~OR[ `~CORS非安全な要請~header名たち$( %要請 の`~header~list$rq ) は空でない ]] ◎ request’s unsafe-request flag is set and either request’s method is not a CORS-safelisted method or CORS-unsafe request-header names with request’s header list is not empty
…ならば:
- %要請 の`応答~tainting$rq ~SET `cors^l ◎ Set request’s response tainting to "cors".
- %~CORS予行~付き応答 ~LET `~HTTP~fetch$( %~fetch~params, ~T ) ◎ Let corsWithPreflightResponse be the result of running HTTP fetch given fetchParams and true.
- ~IF[ %~CORS予行~付き応答 は`~network~error$である ] ⇒ `~cache~entryを消去する$( %要請 ) ◎ If corsWithPreflightResponse is a network error, then clear cache entries using request.
- ~RET %~CORS予行~付き応答 ◎ Return corsWithPreflightResponse.
- %要請 の`応答~tainting$rq ~SET `cors^l ◎ Otherwise • Set request’s response tainting to "cors".
- ~RET `~HTTP~fetch$( %~fetch~params ) ◎ • Return the result of running HTTP fetch given fetchParams.
-
- ~IF[ %再帰的? ~EQ ~T ] ⇒ ~RET %応答 ◎ If recursive is true, then return response.
-
~IF[ %応答 は`~network~error$でない ]~AND[ %応答 は`絞込み応答$でない ]: ◎ If response is not a network error and response is not a filtered response, then:
-
~IF[ %要請 の`応答~tainting$rq ~EQ `cors^l ]: ◎ If request’s response tainting is "cors", then:
- %~header名たち ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Access-Control-Expose-Headers$h ) ◎ Let headerNames be the result of extracting header list values given `Access-Control-Expose-Headers` and response’s header list.
-
~IF[ %~header名たち ~NIN { ~NULL, `失敗^i } ]: ◎ ↓
- ~IF[ %要請 の`資格証~mode$rq ~NEQ `include^l ]~AND[ `*^bl ~IN %~header名たち ] ⇒ %応答 の`~CORSに公開される~header名~list$rs ~SET %応答 の`~header~list$rs内の各`~header$の`名前$hdからなる~list — ここで、各~名前は,~list内で一意にする ◎ If request’s credentials mode is not "include" and headerNames contains `*`, then set response’s CORS-exposed header-name list to all unique header names in response’s header list.
-
~ELSE ⇒ %応答 の`~CORSに公開される~header名~list$rs ~SET %~header名たち ◎ Otherwise, if headerNames is not null or failure, then set response’s CORS-exposed header-name list to headerNames.
注記: この時点でも, %~header名たち のいずれかは `*^bl であり得るが、合致する`~header$は[ `名前$hd ~EQ `*^bl ]を満たすものに限られることになる。 ◎ One of the headerNames can still be `*` at this point, but will only match a header whose name is `*`.
-
%応答 ~SET %応答 を`内部~応答$とする`絞込み応答$であって, %要請 の`応答~tainting$rqに応じて 次で与えられるもの: ◎ Set response to the following filtered response with response as its internal response, depending on request’s response tainting:
- `basic^l
- `基本~絞込み応答$ ◎ basic filtered response
- `cors^l
- `~CORS絞込み応答$ ◎ CORS filtered response
- `opaque^l
- `不透明な絞込み応答$ ◎ opaque filtered response
-
- %内部~応答 ~LET %応答 に応じて ⇒# `~network~error$であるならば %応答 / ~ELSE_ %応答 の`内部~応答$ ◎ Let internalResponse be response, if response is a network error, and response’s internal response otherwise.
-
~IF[ %内部~応答 の`~URL~list$rsは`空$である ] ⇒ %内部~応答 の`~URL~list$rs ~SET %要請 の`~URL~list$rqを`~cloneする$ ◎ If internalResponse’s URL list is empty, then set it to a clone of request’s URL list.
注記: `応答$の`~URL~list$rsは、空になり得る(例えば、当の応答は `about:^c ~URLを表現する場合)。 ◎ A response’s URL list can be empty (for example, when the response represents an about URL).
- ~IF[ %要請 の`計時許容に失敗した~flag$rq ~EQ ~F ] ⇒ %内部~応答 の`計時許容に合格した~flag$rs ~SET ~T ◎ If request’s timing allow failed flag is unset, then set internalResponse’s timing allow passed flag.
- %内部~応答 の`~CSP~listを設定する$ ◎ Set internalResponse’s CSP list.
-
~IF[ %応答 は`~network~error$でない ]~AND[ 次のいずれかの結果 ~EQ `阻止される^i ]…: ◎ If response is not a network error and any of the following algorithms returns blocked, then set response and internalResponse to a network error:
- %要請 に対する %内部~応答 は,混在d内容として阻止されるべきか? `MIX$r ◎ should internalResponse to request be blocked as mixed content [MIX]
- %要請 に対する %内部~応答 は,~CSPにより阻止されるべきか? ◎ should internalResponse to request be blocked by Content Security Policy
- %要請 に対する %内部~応答 は,~MIME型に因り阻止されるべきか? ◎ should internalResponse to request be blocked due to its MIME type
- %要請 に対する %内部~応答 は,~nosniffに因り阻止されるべきか? ◎ should internalResponse to request be blocked due to nosniff
…ならば ⇒ ( %応答, %内部~応答 ) ~SET ( `~network~error$, `~network~error$ ) 【!同一の個? 】 ◎ ↑
-
~IF[ %応答 の`種別$rs ~EQ `opaque^l ]~AND[ %内部~応答 の`状態s$rs ~EQ `206$st ]~AND[ %内部~応答 の`範囲が要請された~flag$rs ~EQ ~T ]~AND[ %要請 の`~header~list$rq内に[ `Range$h を`名前に持つ~header$ ]は無い ] ⇒# %応答 ~SET `~network~error$; %内部~応答 ~SET `~network~error$ ◎ If response’s type is "opaque", internalResponse’s status is 206, internalResponse’s range-requested flag is set, and request’s header list does not contain `Range`, then set response and internalResponse to a network error.
注記: 伝統的に,~APIは、範囲が要請されなかった場合でも範囲~付き応答を受容する。 この段は、[ 過去の範囲~付き要請からの部分的~応答 ]が,範囲~要請を為さなかった~APIに供されることを防止する。 ◎ Traditionally, APIs accept a ranged response even if a range was not requested. This prevents a partial response from an earlier ranged request being provided to an API that did not make a range request.
この段は、次のような攻撃を防止する: ◎ Further details ◎ The above steps prevent the following attack:
~media要素を利用して,非同一-生成元~HTML資源のある範囲が要請されたとする。 これは妥当でない~mediaになるが、応答の~cloneへの参照は,~sw内に維持され得る。 これは、後で~script要素の~fetchに対する応答として利用され得る。 部分的~応答が妥当な~JSであった場合(一体としての資源はそうでなくとも)、それを実行すると私的~dataが漏洩されることになる。 ◎ A media element is used to request a range of a cross-origin HTML resource. Although this is invalid media, a reference to a clone of the response can be retained in a service worker. This can later be used as the response to a script element’s fetch. If the partial response is valid JavaScript (even though the whole resource is not), executing it would leak private data.
-
~IF[ %応答 は`~network~error$でない ]~AND[[ %要請 の`~method$rq ~IN { `HEAD$hm, `CONNECT$hm } ]~OR[ %内部~応答 の`状態s$rs は `~null本体~状態s$である ]] ⇒ %内部~応答 の`本体$rs ~SET ~NULL — 以降、本体への~enqueueはすべて~~無視する ◎ If response is not a network error and either request’s method is `HEAD` or `CONNECT`, or internalResponse’s status is a null body status, set internalResponse’s body to null and disregard any enqueuing toward it (if any).
注記: これは、~HTTPに違反する~server用に ~errorの取扱いを標準~化する。 ◎ This standardizes the error handling for servers that violate HTTP.
-
~IF[ %要請 の`完全性~metadata$rq ~NEQ 空~文字列 ]: ◎ If request’s integrity metadata is not the empty string, then:
- %本体~errorを処理する ~LET 次を走らす手続き ⇒ `~fetch終結$( %~fetch~params, `~network~error$ ) ◎ Let processBodyError be this step: run fetch finale given fetchParams and a network error.
- ~IF[ %要請 の`応答~tainting$rq ~EQ `opaque^l ]~OR[ %応答 は`~network~error$である ]~OR[ %応答 の`本体$rs ~EQ ~NULL ] ⇒# %本体~errorを処理する( ); ~RET ◎ If request’s response tainting is "opaque", response is a network error, or response’s body is null, then run processBodyError and abort these steps.
-
%本体を処理する ~LET 所与の ( %~byte列 ) に対し,次を走らす手続き: ◎ Let processBody given bytes be these steps:
- ~IF[ `応答は~metadata~listに合致するか?$( %~byte列, %要請 の`完全性~metadata$rq ) ~EQ ~F `SRI$r ] ⇒# %本体~errorを処理する(); ~RET ◎ If bytes do not match request’s integrity metadata, then run processBodyError and abort these steps. [SRI]
- %応答 の`本体$rs ~SET 次の結果を成す`本体$ ⇒ `本体と内容~型を安全に抽出する$( %~byte列 ) ◎ Set response’s body to the first return value of safely extracting bytes.
- `~fetch終結$( %~fetch~params, %応答 ) ◎ Run fetch finale given fetchParams and response.
- `本体を全部的に読取る$( %応答 の`本体$rs, %本体を処理する, %本体~errorを処理する ) ◎ Fully read response’s body given processBody and processBodyError.
- ~ELSE ⇒ `~fetch終結$( %~fetch~params, %応答 ) ◎ Otherwise, run fetch finale given fetchParams and response.
`~fetch終結@ は、所与の ( `~fetch~params$ %~fetch~params, `応答$ %応答 ) に対し,次の手続きを走らす: ◎ The fetch finale, given a fetch params fetchParams and a response response, run these steps:
- %応答を処理する ~LET %~fetch~params の`応答を処理する$fP ◎ ↓
- ~IF[ %応答を処理する ~NEQ ~NULL ] ⇒ 次を走らす`~fetch~taskを~queueする$( %~fetch~params の`~taskの行先$fP ) ⇒ %応答を処理する( %応答 ) ◎ If fetchParams’s process response is non-null, then queue a fetch task to run fetchParams’s process response given response, with fetchParams’s task destination.
- %応答の本体の終端を処理する ~LET %~fetch~params の`応答の本体の終端を処理する$fP ◎ ↓
-
~IF[ %応答の本体の終端を処理する ~NEQ ~NULL ]: ◎ If fetchParams’s process response end-of-body is non-null, then:
- %本体を処理する ~LET 所与の ( %~NULLまたは~byte列 ) に対し,次を走らす手続き ⇒ %応答の本体の終端を処理する( %応答, %~NULLまたは~byte列 ) ◎ Let processBody given nullOrBytes be this step: run fetchParams’s process response end-of-body given response and nullOrBytes.
- %本体~errorを処理する ~LET 次を走らす手続き ⇒ %応答の本体の終端を処理する( %応答, `失敗^i ) ◎ Let processBodyError be this step: run fetchParams’s process response end-of-body given response and failure.
- ~IF[ %応答 の`本体$rs ~EQ ~NULL ] ⇒ 次を走らす`~fetch~taskを~queueする$( %~fetch~params の`~taskの行先$fP ) ⇒ %本体を処理する( ~NULL ) ◎ If response’s body is null, then queue a fetch task to run processBody given null, with fetchParams’s task destination.
- ~ELSE ⇒ `本体を全部的に読取る$( %応答 の`本体$rs, %本体を処理する, %本体~errorを処理する, %~fetch~params の`~taskの行先$fP ) ◎ Otherwise, fully read response’s body given processBody, processBodyError, and fetchParams’s task destination.
-
次のいずれかが満たされるまで待機する:
- %応答 の`本体$rs ~EQ ~NULL
- %応答 の`本体$rs の`~stream$bd は[ `~closeされた$RS / `~errorした$RS ]
- %要請 の`~done~flag$rq ~SET ~T ◎ and then set request’s done flag.
4.2. ~scheme~fetch
`~scheme~fetch@ を遂行するときは、所与の ( `~fetch~params$ %~fetch~params ) に対し,次の手続きを走らす: ◎ To scheme fetch, given a fetch params fetchParams:\
- %要請 ~LET %~fetch~params の`要請$fP ◎ let request be fetchParams’s request,\
-
%要請 の`現在の~URL$rq の`~scheme$urlに応じて: ◎ switch on request’s current URL’s scheme, and run the associated steps:
- `about^l
-
- %~url ~LET %要請 の`現在の~URL$rq ◎ ↓
- ~IF[ %~url の`基底~URL不可$url ~EQ ~T ]~AND[ %~url の`~path$urlは 単独の文字列 `blank^l からなる ] ⇒ ~RET 次のように設定された,新たな`応答$ ⇒# `状態s~message$rs ~SET `OK^bl, `~header~list$rs ~SET « `新たな~header$( `Content-Type$h / `text/html;charset=utf-8^bl ) », `本体$rs ~SET 空~byte列 ◎ If request’s current URL’s cannot-be-a-base-URL is true and path contains a single string "blank", then return a new response whose status message is `OK`, header list consist of a single header whose name is `Content-Type` and value is `text/html;charset=utf-8`, and body is the empty byte sequence.
- ~RET `~network~error$ ◎ Otherwise, return a network error.
注記: `about:config^l に類する`~URL$は、`~navi$の間に取扱われ,`~fetch$の文脈~下では`~network~error$になる。 ◎ URLs such as "about:config" are handled during navigation and result in a network error in the context of fetching.
- `blob^l
-
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- %blob ~LET %要請 の`現在の~URL$rqの`~blob~URL~entry$urlの`~obj$bU ◎ Let blob be request’s current URL’s blob URL entry’s object.
-
~IF[ %要請 の`~method$rq ~NEQ `GET$hm ]~OR[ %blob は `Blob$I ~objでない `FILEAPI$r ] ⇒ ~RET `~network~error$ ◎ If request’s method is not `GET` or blob is not a Blob object, then return a network error. [FILEAPI]
注記: `GET^hm `~method$の制約には、相互運用可能にする以外に有用な目的はない。 ◎ The `GET` method restriction serves no useful purpose other than being interoperable.
- %応答 ~LET 次のように設定された,新たな`応答$ ⇒ `状態s~message$rs ~SET `OK^bl ◎ Let response be a new response whose status message is `OK`.
- %応答 の`~header~list$rsに`~headerを付加する$( `Content-Length$h / %blob の `size$mF 属性~値 ) ◎ Append `Content-Length`/blob’s size attribute value to response’s header list.
- %応答 の`~header~list$rsに`~headerを付加する$( `Content-Type$h / %blob の `type$mF 属性~値 ) ◎ Append `Content-Type`/blob’s type attribute value to response’s header list.
- %応答 の`本体$rs ~SET %blob 上で`読取n演算$を遂行した結果 ◎ Set response’s body to the result of performing the read operation on blob.
- ~RET %応答 ◎ Return response.
- 前~段が`中止されたときは$ ⇒ ~RET [ `終了時$の %中止~flag ~NEQ ε ならば `中止~network~error$ / ~ELSE_ `~network~error$ ] ◎ If aborted, then: • Let aborted be the termination’s aborted flag. • If aborted is set, then return an aborted network error. • Return a network error.
-
- `data^l
-
- %~dataURL構造体 ~LET `~data_URL処理器$( %要請 の`現在の~URL$rq ) ◎ Let dataURLStruct be the result of running the data: URL processor on request’s current URL.
- ~IF[ %~dataURL構造体 ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If dataURLStruct is failure, then return a network error.
- ~RET 次のように設定された,新たな`応答$ ⇒# `状態s~message$rs ~SET `OK^bl, `~header~list$rs ~SET « `新たな~header$( `Content-Type$h / `~MIME型を~byte列に直列化する$( %~dataURL構造体 の`~MIME型$dU ) ) », `本体$rs ~SET %~dataURL構造体 の`本体$dU ◎ Return a response whose status message is `OK`, header list consist of a single header whose name is `Content-Type` and value is dataURLStruct’s MIME type, serialized, and body is dataURLStruct’s body.
- `file^l
- 今の所、あいにく file `~URL$については, `left as an exercise for the reader^en である。 【実装に委ねられる】 ◎ For now, unfortunate as it is, file URLs are left as an exercise for the reader.
- 疑わしい場合は`~network~error$を返すこと。 ◎ When in doubt, return a network error.
- `~HTTP_S~scheme$
- ~RET `~HTTP~fetch$( %~fetch~params ) ◎ Return the result of running HTTP fetch given fetchParams.
- その他 ◎ Otherwise
- ~RET `~network~error$ ◎ Return a network error.
4.3. ~HTTP~fetch
`~HTTP~fetch@ を遂行するときは、所与の ( `~fetch~params$ %~fetch~params, 真偽値 %~CORS予行を為すか?(省略時は ~F ) ) に対し,次の手続きを走らす: ◎ To HTTP fetch, given a fetch params fetchParams and an optional boolean makeCORSPreflight (default false), run these steps:
- %要請 ~LET %~fetch~params の`要請$fP ◎ Let request be fetchParams’s request.
- %応答 ~LET ~NULL ◎ Let response be null.
- %実際の応答 ~LET ~NULL ◎ Let actualResponse be null.
-
~IF[ %要請 の`~sw~mode$rq ~EQ `all^l ]: ◎ If request’s service-workers mode is "all", then:
- %~sw用の要請 ~LET `要請を~cloneする$( %要請 ) ◎ Let requestForServiceWorker be a clone of request.
- %応答 ~SET `~fetchを取扱う$( %~sw用の要請 ) `HTML$r `SW$r ◎ Set response to the result of invoking handle fetch for requestForServiceWorker. [HTML] [SW]
-
~IF[ %応答 ~NEQ ~NULL ]: ◎ If response is not null, then:
- ~IF[ %要請 の`本体$rq ~NEQ ~NULL ] ⇒ %要請 の`本体$rqを`取消す$RS( `undefined^jv ) ◎ If request’s body is non-null, then cancel request’s body with undefined.
- %実際の応答 ~SET %応答 に応じて ⇒# `絞込み応答$でないならば %応答 / ~ELSE_ %応答 の`内部~応答$ ◎ Set actualResponse to response, if response is not a filtered response, and to response’s internal response otherwise.
-
~IF[ 次のいずれかが満たされる ]…: ◎ If one of the following is true
- %応答 の`種別$rs ~EQ `error^l ◎ response’s type is "error"
- [ %要請 の`~mode$rq ~EQ `same-origin^l ]~AND[ %応答 の`種別$rs ~EQ `cors^l ] ◎ request’s mode is "same-origin" and response’s type is "cors"
- [ %要請 の`~mode$rq ~NEQ `no-cors^l ]~AND[ %応答 の`種別$rs ~EQ `opaque^l ] ◎ request’s mode is not "no-cors" and response’s type is "opaque"
- [ %要請 の`~redirect~mode$rq ~NEQ `manual^l ]~AND[ %応答 の`種別$rs ~EQ `opaqueredirect^l ] ◎ request’s redirect mode is not "manual" and response’s type is "opaqueredirect"
- [ %要請 の`~redirect~mode$rq ~NEQ `follow^l ]~AND[ %応答 の`~URL~list$rs内に複数の~itemがある ] ◎ request’s redirect mode is not "follow" and response’s URL list has more than one item.
…ならば ⇒ ~RET `~network~error$: ◎ then return a network error.
-
~IF[ %応答 ~EQ ~NULL ]: ◎ If response is null, then:
-
~IF[ %~CORS予行を為すか? ~EQ ~T ]~AND[ 次のいずれかが満たされる ]…: ◎ If makeCORSPreflight is true and one of these conditions is true:
-
[ `~methodも合致している~cache~entry$( %要請, %要請 の`~method$rq ) は空である ]~AND[ %要請 は、次のいずれかを満たす ]:
- `~method$rqは `~CORS安全とされる~method$でない
- `~CORS予行~利用~flag$rq ~EQ ~T
- `~CORS非安全な要請~header名たち$( %要請 の`~header~list$rq ) 内のある名前に対し ⇒ `~header名も合致している~cache~entry$( %要請, 名前 ) は空である ◎ There is at least one item in the CORS-unsafe request-header names with request’s header list for which there is no header-name cache entry match using request.
…ならば: ◎ Then:
- %予行~応答 ~LET `~CORS予行~fetch$( %要請 ) ◎ Let preflightResponse be the result of running CORS-preflight fetch given request.
- ~IF[ %予行~応答 は`~network~error$である ] ⇒ ~RET %予行~応答 ◎ If preflightResponse is a network error, then return preflightResponse.
注記: この段は、`~CORS予行~cache$を検査した上で,相応しい~entryがなければ`~CORS予行~fetch$を遂行し、成功したならば この~cacheを拡充する。 `~CORS予行~fetch$の目的は、`~fetch$された資源が`~CORS~protocol$下に~~置かれることを確保することである。 この~cacheは、`~CORS予行~fetch$の回数を最小限にするためにある。 ◎ This step checks the CORS-preflight cache and if there is no suitable entry it performs a CORS-preflight fetch which, if successful, populates the cache. The purpose of the CORS-preflight fetch is to ensure the fetched resource is familiar with the CORS protocol. The cache is there to minimize the number of CORS-preflight fetches.
-
-
~IF[ %要請 の`~redirect~mode$rq ~EQ `follow^l ] ⇒ %要請 の`~sw~mode$rq ~SET `none^l ◎ If request’s redirect mode is "follow", then set request’s service-workers mode to "none".
注記: (~swとは~~対照的に)~networkから来る~redirectは、~swには公開されない。 ◎ Redirects coming from the network (as opposed to from a service worker) are not to be exposed to a service worker.
- %実際の応答 ~SET `~HTTP~network-or-cache~fetch$( %~fetch~params ) ◎ Set response and actualResponse to the result of running HTTP-network-or-cache fetch given fetchParams.
- %応答 ~SET %実際の応答 ◎ ↑
-
~IF[ %要請 の`応答~tainting$rq ~EQ `cors^l ]~AND[ `~CORS検査$( %要請, %応答 ) ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If request’s response tainting is "cors" and a CORS check for request and response returns failure, then return a network error.
注記: `~CORS検査$は、[ `状態s$rs ~IN { `304$st, `407$st } なる`応答$ / それが~~懸案になる~swからの`応答$ ]には適用されないので、ここで適用される。 ◎ As the CORS check is not to be applied to responses whose status is 304 or 407, or responses from a service worker for that matter, it is applied here.
- ~IF[ `~TAO検査$( %要請, %応答 ) ~EQ `失敗^i ] ⇒ %要請 の`計時許容に失敗した~flag$rq ~SET ~T ◎ If the TAO check for request and response returns failure, then set request’s timing allow failed flag.
-
-
~IF[ `opaque^l ~IN { %要請 の`応答~tainting$rq, %応答 の`種別$rs } ]~AND[ `非同一-生成元~資源~施策~検査$( %要請 の`生成元$rq, %要請 の`~client$rq, %要請 の`行先$rq, %実際の応答 ) ~EQ `阻止される^i ] ⇒ ~RET `~network~error$ ◎ If either request’s response tainting or response’s type is "opaque", and the cross-origin resource policy check with request’s origin, request’s client, request’s destination, and actualResponse returns blocked, then return a network error.
注記: `非同一-生成元~資源~施策~検査$は、[ ~network/~sw ]から来た応答~用に走る。 これは、`~CORS検査$とは異なる — [ %要請 の`~client$rq, ~sw ]の埋込元~施策は異なり得るので。 ◎ The cross-origin resource policy check runs for responses coming from the network and responses coming from the service worker. This is different from the CORS check, as request’s client and the service worker can have different embedder policies.
-
~IF[ %実際の応答 の`状態s$rsは`~redirect状態s$である ]: ◎ If actualResponse’s status is a redirect status, then:
-
~IF[ %実際の応答 の`状態s$rs ~NEQ `303$st ]~AND[ %要請 の`本体$rq ~NEQ ~NULL ]~AND[ `接続$は~HTTP2を利用している ] ⇒ ~UAは `RST_STREAM^c ~frameを伝送してもヨイ — また,そうすることが奨励される。 ◎ If actualResponse’s status is not 303, request’s body is not null, and the connection uses HTTP/2, then user agents may, and are even encouraged to, transmit an RST_STREAM frame.
注記: ある種の~communityにおいては、 `303$st は特別な状態sに帰するとみなされ,除外される。 ◎ 303 is excluded as certain communities ascribe special status to it.
-
%要請 の`~redirect~mode$rq に応じて: ◎ Switch on request’s redirect mode:
- `error^l
- %応答 ~SET `~network~error$ ◎ Set response to a network error.
- `manual^l
- %応答 ~SET `内部~応答$が %実際の応答 にされた,`不透明~redirect絞込み応答$ ◎ Set response to an opaque-redirect filtered response whose internal response is actualResponse.
- `follow^l
- %応答 ~SET `~HTTP~redirect~fetch$( %~fetch~params, %応答 ) ◎ Set response to the result of running HTTP-redirect fetch given fetchParams and response.
-
-
~RET %応答 ◎ Return response.\
注記: 手続きはここで終わるが、その後も概して, %実際の応答 の`本体$rsの`~stream$bdには ~byte列が~enqueueされ続ける。 ◎ Typically actualResponse’s body’s stream is still being enqueued to after returning.
4.4. ~HTTP~redirect~fetch
`~HTTP~redirect~fetch@ を遂行するときは、所与の ( `~fetch~params$ %~fetch~params, `応答$ %応答 ) に対し,次の手続きを走らす: ◎ To HTTP-redirect fetch, given a fetch params fetchParams and a response response, run these steps:
- %要請 ~LET %~fetch~params の`要請$fP ◎ Let request be fetchParams’s request.
- %実際の応答 ~LET %応答 に応じて ⇒# `絞込み応答$でないならば %応答 / ~ELSE_ %応答 の`内部~応答$ ◎ Let actualResponse be response, if response is not a filtered response, and response’s internal response otherwise.
- %~Location~URL ~LET `~Location~URLを得る$( %実際の応答, %要請 の`現在の~URL$rqの`素片$url ) ◎ Let locationURL be actualResponse’s location URL given request’s current URL’s fragment.
- ~IF[ %~Location~URL ~EQ ~NULL ] ⇒ ~RET %応答 ◎ If locationURL is null, then return response.
- ~IF[ %~Location~URL ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If locationURL is failure, then return a network error.
- ~IF[ %~Location~URL の`~scheme$urlは`~HTTP_S~scheme$でない ] ⇒ ~RET `~network~error$ ◎ If locationURL’s scheme is not an HTTP(S) scheme, then return a network error.
- ~IF[ %要請 の`~redirect数$rq ~EQ 20 ] ⇒ ~RET `~network~error$ ◎ If request’s redirect count is twenty, return a network error.
- %要請 の`~redirect数$rq ~INCBY 1 ◎ Increase request’s redirect count by one.
- ~IF[ %要請 の`~mode$rq ~EQ `cors^l ]~AND[ %~Location~URL は`資格証を含んで$いる ]~AND[ ( %要請 の`生成元$rq, %~Location~URL の`生成元$url ) は`同一-生成元$`でない^em ] ⇒ ~RET `~network~error$ ◎ If request’s mode is "cors", locationURL includes credentials, and request’s origin is not same origin with locationURL’s origin, then return a network error.
-
~IF[ %要請 の`応答~tainting$rq ~EQ `cors^l ]~AND[ %~Location~URL は`資格証を含んで$いる ] ⇒ ~RET `~network~error$ ◎ If request’s response tainting is "cors" and locationURL includes credentials, then return a network error.
注記: これは、非同一-生成元~資源による同一-生成元~URLへの~redirectを捕える。 ◎ This catches a cross-origin resource redirecting to a same-origin URL.
- ~IF[ %実際の応答 の`状態s$rs ~NEQ `303$st ]~AND[ %要請 の`本体$rq ~NEQ ~NULL ]~AND[ %要請 の`本体$rqの`~source$bd ~EQ ~NULL ] ⇒ ~RET `~network~error$ ◎ If actualResponse’s status is not 303, request’s body is non-null, and request’s body’s source is null, then return a network error.
- ~IF[ ( %~Location~URL の`生成元$url, %要請 の`現在の~URL$rqの`生成元$rq ) は`同一-生成元$でない ]~AND[ ( %要請 の`生成元$url, %要請 の`現在の~URL$rqの`生成元$rq ) は`同一-生成元$でない ] ⇒ %要請 の`~tainted生成元~flag$rq ~SET ~T ◎ If locationURL’s origin is not same origin with request’s current URL’s origin and request’s origin is not same origin with request’s current URL’s origin, then set request’s tainted origin flag.
-
~IF[[ %実際の応答 の`状態s$rs ~IN { `301$st, `302$st } ]~AND[ %要請 の`~method$rq ~EQ `POST$hm ]]~OR[[ %実際の応答 の`状態s$rs ~EQ `303$st ]~AND[ %要請 の`~method$rq ~NIN { `GET$hm, `HEAD$hm } ]]: ◎ If one of the following is true • actualResponse’s status is 301 or 302 and request’s method is `POST` • actualResponse’s status is 303 and request’s method is not `GET` or `HEAD` ◎ then:
- %要請 の ⇒# `~method$rq ~SET `GET$hm; `本体$rq ~SET ~NULL ◎ Set request’s method to `GET` and request’s body to null.
- `要請~本体~header名$を成す ~EACH( %~header名 ) に対し ⇒ %要請 の`~header~list$rqから`~headerを削除する$( %~header名 ) ◎ For each headerName of request-body-header name, delete headerName from request’s header list.
-
~IF[ %要請 の`本体$rq ~NEQ ~NULL ] ⇒ %要請 の`本体$rq ~SET 次の結果を成す`本体$ ⇒ `本体と内容~型を安全に抽出する$( %要請 の`本体$rqの`~source$bd ) ◎ If request’s body is non-null, then set request’s body to the first return value of safely extracting request’s body’s source.
注記: `~source$bdが ~NULL でないことは、すでに検査~済み。 ◎ request’s body’s source’s nullity has already been checked.
- %要請 の`~URL~list$rqに %~Location~URL を付加する ◎ Append locationURL to request’s URL list.
- `~referrer施策を設定する$( %要請, %実際の応答 ) `REFERRER$r ◎ Invoke set request’s referrer policy on redirect on request and actualResponse. [REFERRER]
-
~RET `~main~fetch$( %~fetch~params, ~T ) ◎ Return the result of running main fetch given fetchParams and true.
注記: %要請 の`応答~tainting$rqが正しくなるようにするため、`~main~fetch$を呼出す必要がある。 ◎ This has to invoke main fetch to get request’s response tainting correct.
4.6. ~HTTP~network-or-cache~fetch
`~HTTP~network-or-cache~fetch@ を遂行するときは、所与の ( `~fetch~params$ %~fetch~params, 真偽値 %認証~fetchか?(省略時は ~F ) ) に対し,次の手続きを走らす: ◎ To HTTP-network-or-cache fetch, given a fetch params fetchParams and an optional boolean isAuthenticationFetch (default false), run these steps:
注記: `HTTP Range Requests^cite `HTTP-RANGE$r にしたがって, 部分的な内容の~cache法を~supportする実装もあるが、~browser~cacheからは広く~supportされていない。 ◎ Some implementations might support caching of partial content, as per HTTP Range Requests. However, this is not widely supported by browser caches. [HTTP-RANGE]
- %要請 ~LET %~fetch~params の`要請$fP ◎ Let request be fetchParams’s request.
- %~http~fetch~params ~LET ~NULL ◎ Let httpFetchParams be null.
- %~http要請 ~LET ~NULL ◎ Let httpRequest be null.
- %応答 ~LET ~NULL ◎ Let response be null.
- %格納-済み応答 ~LET ~NULL ◎ Let storedResponse be null.
- %~http~cache ~LET ~NULL ◎ Let httpCache be null.
- %再検証-中? ~LET ~F ◎ Let the revalidatingFlag be unset.
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- ~IF[ %要請 の`~window$rq ~EQ `no-window^l ]~AND[ %要請 の`~redirect~mode$rq ~EQ `error^l ] ⇒# %~http~fetch~params ~SET %~fetch~params; %~http要請 ~SET %要請 ◎ If request’s window is "no-window" and request’s redirect mode is "error", then set httpFetchParams to fetchParams and httpRequest to request.
-
~ELSE: ◎ Otherwise:
-
%~http要請 ~SET `要請を~cloneする$( %要請 ) ◎ Set httpRequest to a clone of request.
注記: 実装は、[ %要請 の`本体$rq の`~source$bd ~EQ ~NULL ]のときは,[ %要請 の`本体$rq の`~stream$bdを二叉化するのを避ける ]ことが奨励される — その事例では、必要になる本体は 1 個だけなので(例えば、~redirectや認証は,~fetchを失敗させることになる)。 ◎ Implementations are encouraged to avoid teeing request’s body’s stream when request’s body’s source is null as only a single body is needed in that case. E.g., when request’s body’s source is null, redirects and authentication will end up failing the fetch.
- %~http~fetch~params ~SET %~fetch~params の複製 ◎ Set httpFetchParams to a copy of fetchParams.
- %~http~fetch~params の`要請$fP ~SET %~http要請 ◎ Set httpFetchParams’s request to httpRequest.
-
-
%資格証を含めるか? ~LET [ 次のいずれかが満たされるならば ~T / ~ELSE_ ~F ]:
- %要請 の`資格証~mode$rq ~EQ `include^l
- [ %要請 の`資格証~mode$rq ~EQ `same-origin^l ]~AND[ `応答~tainting$rq ~EQ `basic^l ]
- %Content-Length値 ~LET ~NULL ◎ Let contentLengthValue be null.
- ~IF[ %~http要請 の`本体$rq ~EQ ~NULL ]~AND[ %~http要請 の`~method$rq ~IN { `POST$hm, `PUT$hm } ] ⇒ %Content-Length値 ~SET `0^bl ◎ If httpRequest’s body is null and httpRequest’s method is `POST` or `PUT`, then set contentLengthValue to `0`.
- ~IF[ %~http要請 の`本体$rq ~NEQ ~NULL ]~AND[ %~http要請 の`本体$rqの`~source$bd ~NEQ ~NULL ] ⇒ %Content-Length値 ~SET `同型に符号化する$( `整数を直列化する$( %~http要請 の`本体$rqの`総~byte数$bd ) ) ◎ If httpRequest’s body is non-null and httpRequest’s body’s source is non-null, then set contentLengthValue to httpRequest’s body’s total bytes, serialized and isomorphic encoded.
- ~IF[ %Content-Length値 ~NEQ ~NULL ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Content-Length$h / %Content-Length値 ) ◎ If contentLengthValue is non-null, append `Content-Length`/contentLengthValue to httpRequest’s header list.
-
~IF[ %Content-Length値 ~NEQ ~NULL ]~AND[ %~http要請 の`~keepalive$rq ~EQ ~T ]: ◎ If contentLengthValue is non-null and httpRequest’s keepalive is true, then:
- %~inflight~keepalive~byte数 ~LET 0 ◎ Let inflightKeepaliveBytes be zero.
- %~group ~LET %~http要請 の`~client$rqの`~fetch~group$ ◎ Let group be httpRequest’s client’s fetch group.
- %~inflight記録~list ~LET [ %~group 内の`~fetch記録$のうち,その`要請$fgが次を満たすもの ]からなる同順の~list ⇒ [ `~keepalive$rq ~EQ ~T ]~AND[ `~done~flag$rq ~EQ ~F ] ◎ Let inflightRecords be the set of fetch records in group whose request’s keepalive is true and done flag is unset.
-
%~inflight記録~list 内の ~EACH( %~fetch記録 ) に対し: ◎ For each fetchRecord in inflightRecords:
- %~inflight要請 ~LET %~fetch記録 の`要請$fg ◎ Let inflightRequest be fetchRecord’s request.
- %~inflight~keepalive~byte数 ~INCBY %~inflight要請 の`本体$rqの`総~byte数$bd ◎ Increment inflightKeepaliveBytes by inflightRequest’s body’s total bytes.
-
~IF[ ( %Content-Length値 ~PLUS %~inflight~keepalive~byte数 ) ~GT 64 KiB ] ⇒ ~RET `~network~error$ ◎ If the sum of contentLengthValue and inflightKeepaliveBytes is greater than 64 kibibytes, then return a network error.
注記: この~~上限 64 KiB 【 `kibibyte^en — 1024 ~byte単位】は、[ `環境~設定群~obj$の外で残存することが許容され, 本体を包含する要請 【~CSP違反~報告など】 ]に対し、その~sizeには上限があり,要請が不定期に残り続けないことを確保するためにある。 ◎ The above limit ensures that requests that are allowed to outlive the environment settings object and contain a body, have a bounded size and are not allowed to stay alive indefinitely.
- ~IF[ %~http要請 の`~referrer$rqは`~URL$である ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Referer$h / 次の結果 ) ⇒ `同型に符号化する$( `~URLを直列化する$( %~http要請 の`~referrer$rq ) ) ◎ If httpRequest’s referrer is a URL, then append `Referer`/httpRequest’s referrer, serialized and isomorphic encoded, to httpRequest’s header list.
- `要請~Origin~headerを付加する$( %~http要請 ) ◎ Append a request `Origin` header for httpRequest.
- ~IF[ %~http要請 の`~header~list$rq内に[ `User-Agent$h を`名前に持つ~header$ ]は無い ] ⇒ ~UAは、次を行うベキである ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `User-Agent$h / `既定の User-Agent 値$ ) ◎ If httpRequest’s header list does not contain `User-Agent`, then user agents should append `User-Agent`/default `User-Agent` value to httpRequest’s header list.
- ~IF[ %~http要請 の`~cache~mode$rq ~EQ `default^l ]~AND[ %~http要請 の`~header~list$rq内に[ `If-Modified-Since$h / `If-None-Match$h / `If-Unmodified-Since$h / `If-Match$h / `If-Range$h ]を`名前に持つ~header$は在る ] ⇒ %要請 の`~cache~mode$rq ~SET `no-store^l ◎ If httpRequest’s cache mode is "default" and httpRequest’s header list contains `If-Modified-Since`, `If-None-Match`, `If-Unmodified-Since`, `If-Match`, or `If-Range`, then set httpRequest’s cache mode to "no-store".
- ~IF[ %~http要請 の`~cache~mode$rq ~EQ `no-cache^l ]~AND[ %~http要請 の`~no-cache時に~cache制御~headerを改変しない~flag$rq ~EQ ~F ]~AND[ %~http要請 の`~header~list$rq内に[ `Cache-Control$h を`名前に持つ~header$ ]は無い ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Cache-Control$h / `max-age=0^bl ) ◎ If httpRequest’s cache mode is "no-cache", httpRequest’s prevent no-cache cache-control header modification flag is unset, and httpRequest’s header list does not contain `Cache-Control`, then append `Cache-Control`/`max-age=0` to httpRequest’s header list.
-
~IF[ %~http要請 の`~cache~mode$rq ~IN { `no-store^l, `reload^l } ]: ◎ If httpRequest’s cache mode is "no-store" or "reload", then:
- ~IF[ %~http要請 の`~header~list$rq内に[ `Pragma$h を`名前に持つ~header$ ]は無い ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Pragma$h / `no-cache^bl ) ◎ If httpRequest’s header list does not contain `Pragma`, then append `Pragma`/`no-cache` to httpRequest’s header list.
- ~IF[ %~http要請 の`~header~list$rq内に[ `Cache-Control$h を`名前に持つ~header$ ]は無い ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Cache-Control$h / `no-cache^bl ) ◎ If httpRequest’s header list does not contain `Cache-Control`, then append `Cache-Control`/`no-cache` to httpRequest’s header list.
-
~IF[ %~http要請 の`~header~list$rq内に[ `Range$h を`名前に持つ~header$ ]は在る ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Accept-Encoding$h / `identity^bl ) ◎ If httpRequest’s header list contains `Range`, then append `Accept-Encoding`/`identity` to httpRequest’s header list.
注記: これは、符号化された`応答$の ある部位に対し `内容~符号法sを取扱う$ときの失敗を避ける。 ◎ This avoids a failure when handling content codings with a part of an encoded response.
加えて, 多くの~server は、[ `identity^bl でない符号化法を受容する場合には、 `Range$h ~headerは無視する ]ものと誤認している。 ◎ Additionally, many servers mistakenly ignore `Range` headers if a non-identity encoding is accepted.
-
~HTTPに則って %~http要請 の`~header~list$rqを改変する — %~http要請 の`~header~list$rq内に[ 所与の`~header$の`名前$hdを`名前に持つ~header$ ]が在る場合には、それを 付加-しないこと。 ◎ Modify httpRequest’s header list per HTTP. Do not append a given header if httpRequest’s header list contains that header’s name.
注記: この段は、何かもっと規範的な形にしたい。 次に挙げる`~header$などは、この時点で必要に応じて 付加される ⇒ `Accept-Encoding$h, `Connection$h, `DNT^h, `Host$h ◎ It would be great if we could make this more normative somehow. At this point headers such as `Accept-Encoding`, `Connection`, `DNT`, and `Host`, are to be appended if necessary.
この時点では、次に挙げる`~header$は含ませないモノトスル ⇒ `Accept$h, `Accept-Charset$h, `Accept-Language$h ◎ `Accept`, `Accept-Charset`, and `Accept-Language` must not be included at this point.
注記: `Accept$h, `Accept-Language$h は、すでに含められている( `fetch()$m が利用されていない限り — それは、既定では後者を含めない)。 また、 `Accept-Charset$h を含めても,~byte列を浪費するだけである。 詳細は、 ~HTTP~header層の~~区分 を見よ。 ◎ `Accept` and `Accept-Language` are already included (unless fetch() is used, which does not include the latter by default), and `Accept-Charset` is a waste of bytes. See HTTP header layer division for more details.
-
`(A)^i:
~IF[ %資格証を含めるか? ~EQ ~T ]: ◎ If includeCredentials is true, then:-
~IF[ ~UAは %~http要請 用の~cookieを阻止するように環境設定されていない( `COOKIES$r の § ~privacyの考慮点 を見よ) ]: ◎ If the user agent is not configured to block cookies for httpRequest (see section 7 of [COOKIES]), then:
- %~cookie ~LET ( ~UAの~cookie保管庫, %~http要請 の`現在の~URL$rq ) を与える下で, `COOKIES$r の "cookie-string" ~algo を走らせた結果 ◎ Let cookies be the result of running the "cookie-string" algorithm (see section 5.4 of [COOKIES]) with the user agent’s cookie store and httpRequest’s current URL.
- ~IF[ %~cookie ~NEQ 空~文字列 ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Cookie$h / %~cookie ) ◎ If cookies is not the empty string, append `Cookie`/cookies to httpRequest’s header list.
- ~IF[ %~http要請 の`~header~list$rq内に[ `Authorization$h を`名前に持つ~header$ ]は在る ] ⇒ ~BREAK `(A)^i ◎ If httpRequest’s header list does not contain `Authorization`, then:
- %権限付与~値 ~LET ~NULL ◎ Let authorizationValue be null.
- ~IF[ %~http要請 用の`認証~entry$は在る ]~AND[[ %~http要請 の`資格証利用URL~flag$rq ~EQ ~F ]~OR[ %~http要請 の`現在の~URL$rqは`資格証を含んで$いない ]] ⇒ %権限付与~値 ~SET `認証~entry$ ◎ If there’s an authentication entry for httpRequest and either httpRequest’s use-URL-credentials flag is unset or httpRequest’s current URL does not include credentials, then set authorizationValue to authentication entry.
- ~ELIF[ %~http要請 の`現在の~URL$rqは`資格証を含んで$いる ]~AND[ %認証~fetchか? ~EQ ~T ] ⇒ %権限付与~値 ~SET %~http要請 の`現在の~URL$rqを `Authorization$h 値に変換- した結果 ◎ Otherwise, if httpRequest’s current URL does include credentials and isAuthenticationFetch is true, set authorizationValue to httpRequest’s current URL, converted to an `Authorization` value.
- ~IF[ %権限付与~値 ~NEQ ~NULL ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Authorization$h / %権限付与~値 ) ◎ If authorizationValue is non-null, then append `Authorization`/authorizationValue to httpRequest’s header list.
-
-
`~proxy認証~entry$がある場合、それを適切に利用する ◎ If there’s a proxy-authentication entry, use it as appropriate.
注記: ここでは意図的に %~http要請 の`資格証~mode$rqに依存しないようにされている。 ◎ This intentionally does not depend on httpRequest’s credentials mode.
- %~http~cache ~SET `~HTTP~cache区分を決定する$( %~http要請 ) ◎ Set httpCache to the result of determining the HTTP cache partition, given httpRequest.
- ~IF[ %~http~cache ~EQ ~NULL ] ⇒ %~http要請 の`~cache~mode$rq~SET `no-store^l ◎ If httpCache is null, then set httpRequest’s cache mode to "no-store".
-
`(B)^i:
~IF[ %~http要請 の`~cache~mode$rq ~NIN { `no-store^l, `reload^l } ]: ◎ If httpRequest’s cache mode is neither "no-store" nor "reload", then:-
%格納-済み応答 ~SET %~http~cache から応答を選定した結果 ⇒ ~IF[ 該当する応答はない ] ⇒ ~BREAK `(B)^i
注記: ~HTTPにより義務付けられているように、これには,依然として `Vary$h `~header$も織り込まれる。
◎ Set storedResponse to the result of selecting a response from the httpCache, possibly needing validation, as per the "Constructing Responses from Caches" chapter of HTTP Caching [HTTP-CACHING], if any. ◎ As mandated by HTTP, this still takes the `Vary` header into account. ◎ If storedResponse is non-null, then: -
~IF[ `~cache~mode$rq ~EQ `default^l ]~AND[ %格納-済み応答 は`~stale-while-revalidate応答$である ]~AND[ %~http要請 の`~client$rq ~NEQ ~NULL ]: ◎ If cache mode is "default", storedResponse is a stale-while-revalidate response, and httpRequest’s client is non-null, then:
- %応答 ~SET %格納-済み応答 ◎ Set response to storedResponse.
- %応答 の`~cache状態$rs ~SET `local^l ◎ Set response’s cache state to "local".
- %再検証-要請 ~LET `要請を~cloneする$( %要請 ) ◎ Let revalidateRequest be a clone of request.
- %再検証-要請 の ⇒# `~cache~mode$rq ~SET `no-cache^l, `~no-cache時に~cache制御~headerを改変しない~flag$rq ~SET ~T, `~sw~mode$rq ~SET `none^l ◎ Set revalidateRequest’s cache mode set to "no-cache". ◎ Set revalidateRequest’s prevent no-cache cache-control header modification flag. ◎ Set revalidateRequest’s service-workers mode set to "none".
- %再検証-~fetch~params ~LET 新たな`~fetch~params$ — その ⇒# `要請$fP ~SET %再検証-要請 ◎ ↓
-
次を`並列的$に遂行する ⇒ `~main~fetch$( %再検証-~fetch~params ) ◎ In parallel, run main fetch given a new fetch params whose request is revalidateRequest.
注記: この~fetchに意味されるのは, %~http~cache の状態を更新することに限られ、対する応答は,別の~cache~accessまで利用されないことになる。 現在の要請に対する応答には、`非新鮮な応答$が利用されることになる。 この~fetchは,~clientの文脈で発行iされるので、消え去った場合,当の要請( %再検証-要請 )は終了されることになる。 ◎ This fetch is only meant to update the state of httpCache and the response will be unused until another cache access. The stale response will be used as the response to current request. This fetch is issued in the context of a client so if it goes away the request will be terminated.
-
~ELSE: ◎ Otherwise:
- ~IF[ %格納-済み応答 は`非新鮮な応答$である ] ⇒ %再検証-中? ~SET ~T ◎ If storedResponse is a stale response, then set the revalidatingFlag.
-
~IF[ %再検証-中? ~EQ ~T ]~AND[ %~http要請 の`~cache~mode$rq ~NIN { `force-cache^l, `only-if-cached^l } ]: ◎ If the revalidatingFlag is set and httpRequest’s cache mode is neither "force-cache" nor "only-if-cached", then:
- ~IF[ %格納-済み応答 の`~header~list$rs内に[ `ETag$h を`名前に持つ~header$ ]は在る ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `If-None-Match$h / その~headerの`値$hd ) ◎ If storedResponse’s header list contains `ETag`, then append `If-None-Match` with its value to httpRequest’s header list.
- ~IF[ %格納-済み応答 の`~header~list$rs内に[ `Last-Modified$h を`名前に持つ~header$ ]は在る ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `If-Modified-Since$h / その~headerの`値$hd ) ◎ If storedResponse’s header list contains `Last-Modified`, then append `If-Modified-Since` with its value to httpRequest’s header list.
注記: `HTTP Caching^cite の 検証~要請の送信-法 も見よ。 `HTTP-CACHING$r ◎ See also the "Sending a Validation Request" chapter of HTTP Caching [HTTP-CACHING].
- ~ELSE ⇒# %応答 ~SET %格納-済み応答; %応答 の`~cache状態$rs ~SET `local^l ◎ Otherwise, set response to storedResponse and set response’s cache state to "local".
-
- 前~段が`中止されたときは$ ⇒ ~RET [ `終了時$の %中止~flag ~NEQ ε ならば `中止~network~error$ / ~ELSE_ `~network~error$ ] ◎ If aborted, then: • Let aborted be the termination’s aborted flag. • If aborted is set, then return an aborted network error. • Return a network error.
-
~IF[ %応答 ~EQ ~NULL ]: ◎ If response is null, then:
- ~IF[ %~http要請 の`~cache~mode$rq ~EQ `only-if-cached^l ] ⇒ ~RET `~network~error$ ◎ If httpRequest’s cache mode is "only-if-cached", then return a network error.
- %回送-応答 ~LET `~HTTP~network~fetch$( %~http~fetch~params, %資格証を含めるか? ) ◎ Let forwardResponse be the result of running HTTP-network fetch given httpFetchParams and includeCredentials.
-
~IF[ %~http要請 の`~method$rqは`安全$でない ]~AND[ %回送-応答 の`状態s$rs ~IN { `200^st 〜 `399^st } ]:
- `HTTP Caching^cite の § 無効化-法 にしたがって, %~http~cache 内の適切な格納-済み応答たちを無効化する `HTTP-CACHING$r
- %格納-済み応答 ~SET ~NULL
-
~IF[ %再検証-中? ~EQ ~T ]~AND[ %回送-応答 の`状態s$rs ~EQ `304$st ]: ◎ If the revalidatingFlag is set and forwardResponse’s status is 304, then:
-
`HTTP Caching^cite の § 検証にあたっての,格納-済み応答の新鮮化-法 に従って, %回送-応答 の`~header~list$rsを利用して %格納-済み応答 の`~header~list$rsを更新する `HTTP-CACHING$r ◎ Update storedResponse’s header list using forwardResponse’s header list, as per the "Freshening Stored Responses upon Validation" chapter of HTTP Caching. [HTTP-CACHING]
注記: これは、~cache内の格納-済み応答も更新する。 ◎ This updates the stored response in cache as well.
- %応答 ~SET %格納-済み応答 ◎ Set response to storedResponse.
-
-
~IF[ %応答 ~EQ ~NULL ]: ◎ If response is null, then:
- %応答 ~SET %回送-応答 ◎ Set response to forwardResponse.
-
`HTTP Caching^cite の § ~cache内への応答の格納-法 にしたがって,%~http~cache 内に[ %~http要請, %回送-応答 ]を格納する `HTTP-CACHING$r ◎ Store httpRequest and forwardResponse in httpCache, as per the "Storing Responses in Caches" chapter of HTTP Caching. [HTTP-CACHING]
注記: %回送-応答 が`~network~error$である場合、これは実質的に,その~network~errorを~cacheする — それは “負な~cache法( `negative caching^en )” と称されることもある。 ◎ If forwardResponse is a network error, this effectively caches the network error, which is sometimes known as "negative caching".
- %応答 の`~URL~list$rs ~SET %~http要請 の`~URL~list$rqを`~cloneする$ ◎ Set response’s URL list to a clone of httpRequest’s URL list.
- ~IF[ %~http要請 の`~header~list$rq内に[ `Range$h を`名前に持つ~header$ ]は在る ] ⇒ %応答 の`範囲が要請された~flag$rs ~SET ~T ◎ If httpRequest’s header list contains `Range`, then set response’s range-requested flag.
-
~IF[ %応答 の`状態s$rs ~EQ `401$st ]~AND[ %~http要請 の`応答~tainting$rq ~NEQ `cors^l ]~AND[ %資格証を含めるか? ~EQ ~T ]~AND[ %要請 の`~window$rqは`環境~設定群~obj$である ]: ◎ If response’s status is 401, httpRequest’s response tainting is not "cors", includeCredentials is true, and request’s window is an environment settings object, then:
- 課題: `WWW-Authenticate$h ~header が複数個ある場合, 与えられていない場合, その構文解析, についてのテスト ◎ Needs testing: multiple `WWW-Authenticate` headers, missing, parsing issues.
-
~IF[ %要請 の`本体$rq ~NEQ ~NULL ]: ◎ If request’s body is non-null, then:
- ~IF[ %要請 の`本体$rqの`~source$bd ~EQ ~NULL ] ⇒ ~RET `~network~error$ ◎ If request’s body’s source is null, then return a network error.
- %要請 の`本体$rq ~SET 次の結果を成す`本体$ ⇒ `本体と内容~型を安全に抽出する$( %要請 の`本体$rqの`~source$bd ) ◎ Set request’s body to the first return value of safely extracting request’s body’s source.
-
~IF[ %要請 の`資格証利用URL~flag$rq ~EQ ~F ]~OR[ %認証~fetchか? ~EQ ~T ]: ◎ If request’s use-URL-credentials flag is unset or isAuthenticationFetch is true, then:
- ~IF[ 進行中の~fetchは`終了され$た ] ⇒ ~RET [ `終了時$の %中止~flag ~NEQ ε ならば `中止~network~error$ / ~ELSE_ `~network~error$ ] ◎ If the ongoing fetch is terminated, then: • Let aborted be the termination’s aborted flag. • If aborted is set, then return an aborted network error. • Return a network error.
- ( %~username, %~password ) ~LET %要請 の`~window$rq において,末端利用者に ( ~username, ~password ) の~~入力を促して得られた結果 【~~入力が拒否された場合について言及されていない。`中止~network~error$を返す?】 ◎ Let username and password be the result of prompting the end user for a username and password, respectively, in request’s window.
- `~URLの~usernameを設定する$( %要請 の`現在の~URL$rq, %~username ) ◎ Set the username given request’s current URL and username.
- `~URLの~passwordを設定する$( %要請 の`現在の~URL$rq, %~password ) ◎ Set the password given request’s current URL and password.
- %応答 ~SET `~HTTP~network-or-cache~fetch$( %~fetch~params, ~T ) ◎ Set response to the result of running HTTP-network-or-cache fetch given fetchParams and true.
-
~IF[ %応答 の`状態s$rs ~EQ `407$st ]: ◎ If response’s status is 407, then:
- ~IF[ %要請 の`~window$rq ~EQ `no-window^l ] ⇒ ~RET `~network~error$ ◎ If request’s window is "no-window", then return a network error.
- 課題: `Proxy-Authenticate$h ~header が複数個ある場合, 与えられていない場合, その構文解析, についてのテスト ◎ Needs testing: multiple `Proxy-Authenticate` headers, missing, parsing issues.
- ~IF[ 進行中の~fetchは`終了され$た ] ⇒ ~RET [ `終了時$の %中止~flag ~NEQ ε ならば `中止~network~error$ / ~ELSE_ `~network~error$ ] ◎ If the ongoing fetch is terminated, then: • Let aborted be the termination’s aborted flag. • If aborted is set, then return an aborted network error. • Return a network error.
-
%要請 の`~window$rqにおいて、末端利用者に対し 適切に 【認証に関する手続きを】 促し,その結果を`~proxy認証~entry$として保存する `HTTP-AUTH$r ◎ Prompt the end user as appropriate in request’s window and store the result as a proxy-authentication entry. [HTTP-AUTH]
注記: ~proxy認証~周辺の詳細は~HTTPにて定義される。 ◎ Remaining details surrounding proxy authentication are defined by HTTP.
- %応答 ~SET `~HTTP~network-or-cache~fetch$( %~fetch~params ) ◎ Set response to the result of running HTTP-network-or-cache fetch given fetchParams.
- ~IF[ %認証~fetchか? ~EQ T ] ⇒ [ %要請, および所与の~realm ]用の`認証~entry$を作成する ◎ If isAuthenticationFetch is true, then create an authentication entry for request and the given realm.
-
~RET %応答
注記: 手続きはここで終わるが、その後も概して, %応答 の`本体$rsの`~stream$bdには~enqueueされ続ける。
◎ Return response. Typically response’s body’s stream is still being enqueued to after returning.
4.7. ~HTTP~network~fetch
`~HTTP~network~fetch@ を遂行するときは、所与の ( `~fetch~params$ %~fetch~params, 真偽値 %資格証を含めるか?(省略時は ~F ) ) に対し,次の手続きを走らす: ◎ To HTTP-network fetch, given a fetch params fetchParams and an optional boolean includeCredentials (default false), run these steps:
- %要請 ~LET %~fetch~params の`要請$fP ◎ Let request be fetchParams’s request.
- %応答 ~LET ~NULL ◎ Let response be null.
- %~http~cache ~LET `~HTTP~cache区分を決定する$( %~http要請 ) ◎ Let httpCache be the result of determining the HTTP cache partition, given httpRequest.
- ~IF[ %~http~cache ~EQ ~NULL ] ⇒ %要請 の`~cache~mode$rq~SET `no-store^l ◎ If httpCache is null, then set request’s cache mode to "no-store".
- %~network区分~key ~LET `~network区分~keyを決定する$( %要請 ) ◎ Let networkPartitionKey be the result of determining the network partition key given request.
-
%接続 ~LET %要請 の`~mode$rqに応じて,次を遂行した結果: ◎ Switch on request’s mode:
- `websocket^l ⇒ `~WebSocket接続を得する$( %要請 の`現在の~URL$rq ) ◎ "websocket" • Let connection be the result of obtaining a WebSocket connection, given request’s current URL.
- ~ELSE_ ⇒ `接続を得する$( %~network区分~key, %要請 の`現在の~URL$rqの`生成元$url, %資格証を含めるか? ) ◎ Otherwise • Let connection be the result of obtaining a connection, given networkPartitionKey, request’s current URL’s origin, and includeCredentials.
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- ~IF[ %接続 ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If connection is failure, return a network error.
- ~IF[ %接続 は~HTTP2接続でない ]~AND[ %要請 の`本体$rq ~NEQ ~NULL ]~AND[ %要請 の`本体$rqの`~source$bd ~EQ ~NULL ] ⇒ %要請 の`~header~list$rqに`~headerを付加する$( `Transfer-Encoding$h / `chunked^bl ) ◎ If connection is not an HTTP/2 connection, request’s body is non-null, and request’s body’s source is null, then append `Transfer-Encoding`/`chunked` to request’s header list.
-
%応答 ~SET 次の各~条項に従う下で、 %要請 を利用して, %接続 越しに,~HTTP要請を為した結果: ◎ Set response to the result of making an HTTP request over connection using request with the following caveats:
- ~HTTPによる関連な要件に従うこと。 `HTTP$r `HTTP-SEMANTICS$r `HTTP-COND$r `HTTP-CACHING$r `HTTP-AUTH$r ◎ Follow the relevant requirements from HTTP. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]
- `~header$すべてが伝送されるまで待機すること。 ◎ Wait until all the headers are transmitted.
-
`応答$のうち,[ `状態s$rs ~IN { `100^st, `102^st 〜 `199^st } ]なるものは無視すること。 ◎ Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored.
注記: この種の`応答$【`暫定-応答$】には、最終的に, “最終” `応答$【`最終-応答$】が後続する。 ◎ These kind of responses are eventually followed by a "final" response.
注記: ~Fetchと~HTTPとの間の正確な重ね方は、依然として~~整理される必要がある。 したがって、ここでの %応答 は,`応答$と~HTTP応答の両者を表現する。 ◎ The exact layering between Fetch and HTTP still needs to be sorted through and therefore response represents both a response and an HTTP response here.
- %応答 は HTTP/1.0 以下の~versionを介して転送されていて、 %要請 の`~header~list$rqは ( `Transfer-Encoding$h / `chunked^bl ) を包含している場合は ⇒ ~RET `~network~error$ ◎ If request’s header list contains `Transfer-Encoding`/`chunked` and response is transferred via HTTP/1.0 or older, then return a network error.
-
~HTTP要請による結果,~TLS~client証明書~dialogになるときは: ◎ If the HTTP request results in a TLS client certificate dialog, then:
- ~IF[ %要請 の`~window$rqは`環境~設定群~obj$である ] ⇒ %要請 の`~window$rqにて~dialogを可用にする ◎ If request’s window is an environment settings object, make the dialog available in request’s window.
- ~ELSE ⇒ ~RET `~network~error$ ◎ Otherwise, return a network error.
-
%要請 の`本体$rq %本体 を伝送するときは,次の手続きを走らす: ◎ To transmit request’s body body, run these steps:
- %要請の本体の終端を処理する ~LET %~fetch~params の`要請の本体の終端を処理する$fP ◎ ↓
- ~IF[ %本体 ~EQ ~NULL ] ⇒ ~IF[ %要請の本体の終端を処理する ~NEQ ~NULL ] ⇒ 次を走らす`~fetch~taskを~queueする$( %~fetch~params の`~taskの行先$fP ) ⇒ %要請の本体の終端を処理する( %~fetch~params の`要請$fP ) ◎ If body is null and fetchParams’s process request end-of-body is non-null, then queue a fetch task given fetchParams’s process request end-of-body and fetchParams’s task destination.
-
~ELSE: ◎ Otherwise, if body is non-null:
-
%本体~chunkを処理する ~LET 所与の ( %~byte列 ) に対し,次を走らす手続き: ◎ Let processBodyChunk given bytes be these steps:
- ~IF[ 進行中の~fetchは`終了され$た ] ⇒ ~RET ◎ If the ongoing fetch is terminated, then abort these steps.
- この段は`並列的$に走らす ⇒ %~byte列 を伝送する 【この段は具体的に何をする?】 ◎ Run this step in parallel: transmit bytes.
- %要請の本体を処理する ~LET %~fetch~params の`要請の本体を処理する$fP ◎ ↓
- ~IF[ %要請の本体を処理する ~NEQ ~NULL ] ⇒ %要請の本体を処理する( %~byte列 の`長さ$ ) ◎ If fetchParams’s process request body is non-null, then run fetchParams’s process request body given bytes’s length.
-
%本体の終端を処理する ~LET 次を走らす手続き: ◎ Let processEndOfBody be these steps:
- ~IF[ 進行中の~fetchは`終了され$た ] ⇒ ~RET ◎ If the ongoing fetch is terminated, then abort these steps.
- ~IF[ %要請の本体を処理する ~NEQ ~NULL ] ⇒ %要請の本体を処理する( 【 %本体 の`総~byte数$bd?】 ) ◎ If fetchParams’s process request end-of-body is non-null, then run fetchParams’s process request end-of-body.
-
%本体~errorを処理する ~LET 所与の ( %~error ) に対し,次を走らす手続き: ◎ Let processBodyError given e be these steps:
- ~IF[ 進行中の~fetchは`終了され$た ] ⇒ ~RET ◎ If the ongoing fetch is terminated, then abort these steps.
- ~IF[ %~error は `AbortError$E 例外である ] ⇒ 進行中の~fetchを`終了させる$( `中止する^i ) ◎ If e is an "AbortError" DOMException, then terminate the ongoing fetch with the aborted flag set.
- ~ELSE ⇒ 進行中の~fetchを`終了させる$() ◎ Otherwise, terminate the ongoing fetch.
- `本体を増分的に読取る$( 次に挙げる引数 ) ⇒# %要請 の`本体$rq, %本体~chunkを処理する, %本体の終端を処理する, %本体~errorを処理する, %~fetch~params の`~taskの行先$fP ◎ Incrementally read request’s body given processBodyChunk, processEndOfBody, processBodyError, and fetchParams’s task destination.
-
-
前~段が`中止されたときは$: ◎ If aborted, then: ◎ ↓• Let aborted be the termination’s aborted flag.
- ~IF[ %接続 は~HTTP2を利用している ] ⇒ `RST_STREAM^c ~frameを伝送する ◎ If connection uses HTTP/2, then transmit an RST_STREAM frame.
- ~RET [ `終了時$の %中止~flag ~NEQ ε ならば `中止~network~error$ / ~ELSE_ `~network~error$ ] ◎ If aborted is set, then return an aborted network error. ◎ Return a network error.
- %~pull~algo ~LET 次を走らす動作 ⇒ ~IF[ 進行中の~fetchは`休止-$している ] ⇒ それを`再開-$する ◎ Let pullAlgorithm be an action that resumes the ongoing fetch if it is suspended.
- %取消~algo ~LET 次を走らす動作 ⇒ 進行中の~fetchを`終了させる$( `中止する^i ) ◎ Let cancelAlgorithm be an action that terminates the ongoing fetch with the aborted flag set.
- %限界水位 ~LET ~LET ~UAが選ぶ[ 有限かつ負でない~number, または `Infinity^jv ] ◎ Let highWaterMark be a non-negative, non-NaN number, chosen by the user agent.
- %~size~algo ~LET `~chunk$~objを受容し,~UAが選ぶ[ 有限かつ負でない~number ]を返す~algo ◎ Let sizeAlgorithm be an algorithm that accepts a chunk object and returns a non-negative, non-NaN, non-infinite number, chosen by the user agent.
- %~stream ~LET `ReadableStream$I を`作成する$RS( %~pull~algo, %取消~algo, %限界水位, %~size~algo ) ◎ Let stream be the result of creating a ReadableStream with pullAlgorithm set to pullAlgorithm, cancelAlgorithm set to cancelAlgorithm, highWaterMark set to highWaterMark, and sizeAlgorithm set to sizeAlgorithm.
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- %応答 の`本体$rs ~SET 次のようにされた新たな`本体$ ⇒ `~stream$bd ~SET %~stream ◎ Set response’s body to a new body whose stream is stream.
-
~IF[ %応答 には`内容$の長さがある ] ⇒ %応答 の`本体$rsの`総~byte数$bd ~SET その長さ ◎ If response has a payload body length, then set response’s body’s total bytes to that payload body length.
【 この条件 “長さがある” の詳細は述べられていないが、例えば `Content-Length$h ~headerにより明示的に指示されている場合が該当するであろう(他にもあり得る)。 HTTP/1.1 においては、 ~message本体の長さを決定できるかどうかに対応すると見受けられる(接続が~closeされるまで判明しない場合もある)。 】
- ~IF[ %応答 は`~network~error$でない ]~AND[ %要請 の`~cache~mode$rq ~NEQ `no-store^l ] ⇒ %~http~cache 内の[ %要請 に対する %応答 ]を更新する ◎ If response is not a network error and request’s cache mode is not "no-store", then update response in httpCache for request.
-
~IF[ %資格証を含めるか? ~EQ ~T ]~AND[ ~UAは %要請 用の~cookieを阻止するように環境設定されていない( `COOKIES$r の § ~privacyの考慮点 を見よ) ] ⇒ %応答 の`~header~list$rs内の ~EACH ( `Set-Cookie$h を`名前に持つ~header$ %~header ) に対し ⇒ ( %~header の`値$hd, %要請 の`現在の~URL$rq ) を与える下で, `COOKIES$r の "set-cookie-string" 構文解析~algo を走らす ◎ If includeCredentials is true and the user agent is not configured to block cookies for request (see section 7 of [COOKIES]), then run the "set-cookie-string" parsing algorithm (see section 5.2 of [COOKIES]) on the value of each header whose name is a byte-case-insensitive match for `Set-Cookie` in response’s header list, if any, and request’s current URL.
注記: これは、利用者の追跡に利用され得る機能性である。 ~FINGERPRINTING ◎ This is a fingerprinting vector.
-
前~段が`中止されたときは$: ◎ If aborted, then:
- ~IF[ `終了時$の %中止~flag ~NEQ ε ] ⇒ %応答 の`中止~flag$rs ~SET ~T ◎ Let aborted be the termination’s aborted flag. ◎ If aborted is set, then set response’s aborted flag.
- ~RET %応答 ◎ Return response.
-
この段の中は、`並列的$に走らす: ◎ Run these steps in parallel:
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
~WHILE 無条件: ◎ While true:
-
~IF[ %応答 の`内容$から 1 個 以上の~byteが伝送された ]: ◎ If one or more bytes have been transmitted from response’s message body, then:
- %~byte列 ~LET 伝送された~byte列 ◎ Let bytes be the transmitted bytes.
- %符号法s ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Content-Encoding$h ) ◎ Let codings be the result of extracting header list values given `Content-Encoding` and response’s header list.
-
%~byte列 ~SET `内容~符号法sを取扱う$( %符号法s, %~byte列 ) ◎ Set bytes to the result of handling content codings given codings and bytes.
注記: これは、依拠し得ていた `Content-Length^h `~header$を依拠できないものにする。 【!*】 ◎ This makes the `Content-Length` header unreliable to the extent that it was reliable to begin with.
- ~IF[ %~byte列 ~EQ `失敗^i ] ⇒ 進行中の~fetchを`終了させる$() ◎ If bytes is failure, then terminate the ongoing fetch.
- %~stream に`~chunkを~enqueueする$RS( %~byte列 を包含している `ArrayBuffer$I を包装している `Uint8Array$I ) ◎ Enqueue a Uint8Array wrapping an ArrayBuffer containing bytes into stream.
- ~IF[ %~stream は`~errorした$RS ] ⇒ 進行中の~fetchを`終了させる$() ◎ If stream is errored, then terminate the ongoing fetch.
- ~IF[ %~stream は`もっと~dataが必要$RSではない ] ⇒ 進行中の~fetchを`休止-$するよう,~UAに依頼する ◎ If stream doesn’t need more data ask the user agent to suspend the ongoing fetch.
- ~ELIF[ %応答 の`内容$用の~byte列の伝送は,正常に終えられた ] ⇒ ~IF[ %~stream は`読取n可能$RSである ] ⇒# %~stream を`~closeする$RS(); ~BREAK ◎ Otherwise, if the bytes transmission for response’s message body is done normally and stream is readable, then close stream and abort these in-parallel steps.
-
-
前~段が`中止されたときは$: ◎ If aborted, then:
-
~IF[ `終了時$の %中止~flag ~NEQ ε ]: ◎ Let aborted be the termination’s aborted flag. ◎ If aborted is set, then:
- %応答 の`中止~flag$rs ~SET ~T ◎ Set response’s aborted flag.
- ~IF[ %~stream は`読取n可能$RSである ] ⇒ %~stream を`~errorにする$RS( `AbortError$E 例外 ) ◎ If stream is readable, error stream with an "AbortError" DOMException.
- ~ELIF[ %~stream は`読取n可能$RSである ] ⇒ %~stream を`~errorにする$RS( `TypeError$E ) ◎ Otherwise, if stream is readable, error stream with a TypeError.
- ~IF[ %接続 は~HTTP2を利用している ] ⇒ `RST_STREAM^c ~frameを伝送する ◎ If connection uses HTTP/2, then transmit an RST_STREAM frame.
-
~ELSE ⇒ ~UAは接続を~closeするベキである — そうすると処理能が悪化するときは除いて ◎ Otherwise, the user agent should close connection unless it would be bad for performance to do so.
注記: 一例として,~UAは、再利用-可能な接続にて,伝送する~byte数が残りわずかしかないと知るならば、接続を~openしたまま保つこともできる。 この事例では、接続を~closeして 次の~fetch用に~handshake処理-をやり直すと,悪化することもあるので。 ◎ For instance, the user agent could keep the connection open if it knows there’s only a few bytes of transfer remaining on a reusable connection. In this case it could be worse to close the connection and go through the handshake process again for the next fetch.
注記: この段を`並列的$に走らせているのは、この時点では, %応答 の`本体$rsが関連するかどうか明瞭でないためである( %応答 は~redirectかもしれない)。 ◎ These are run in parallel as at this point it is unclear whether response’s body is relevant (response might be a redirect).
-
-
-
~RET %応答
注記: 手続きはここで終わるが、その後も概して, %応答 の`本体$rsの`~stream$bdには~enqueueされ続ける。
◎ Return response. Typically response’s body’s stream is still being enqueued to after returning.
4.8. ~CORS予行~fetch
注記: これは、実質的には,`~CORS~protocol$が解されるかどうか見るための~UA実装であり、`~CORS予行~要請$と呼ばれている。 成功したときは、`~CORS予行~fetch$の回数を最小限にするために,`~CORS予行~cache$を拡充する。 ◎ This is effectively the user agent implementation of the check to see if the CORS protocol is understood. The so-called CORS-preflight request. If successful it populates the CORS-preflight cache to minimize the number of these fetches.
`~CORS予行~fetch@ を遂行するときは、所与の ( `要請$ %要請 ) に対し,次を走らす: ◎ To CORS-preflight fetch, given a request request, run these steps:
-
%予行 ~LET 次のように設定された,新たな`要請$ ⇒# `~method$rq ~SET `OPTIONS$hm, `~URL$rq ~SET %要請 の`現在の~URL$rq, `起動元$rq ~SET %要請 の`起動元$rq, `行先$rq ~SET %要請 の`行先$rq, `生成元$rq ~SET %要請 の`生成元$rq, `~referrer$rq ~SET %要請 の`~referrer$rq, `~referrer施策$rq ~SET %要請 の`~referrer施策$rq, `~mode$rq ~SET `cors^l, `~tainted生成元~flag$rq ~SET %要請 の`~tainted生成元~flag$rq, `応答~tainting$rq ~SET `cors^l ◎ Let preflight be a new request whose method is `OPTIONS`, URL is request’s current URL, initiator is request’s initiator, destination is request’s destination, origin is request’s origin, referrer is request’s referrer, referrer policy is request’s referrer policy, mode is "cors", tainted origin flag is request’s tainted origin flag, and response tainting is "cors".
注記: %予行 の`~sw~mode$rqは関わらない — この~algoは、`~HTTP~fetch$ではなく,`~HTTP~network-or-cache~fetch$を利用するので。 ◎ The service-workers mode of preflight does not matter as this algorithm uses HTTP-network-or-cache fetch rather than HTTP fetch.
- %予行 の`~header~list$rqに`~headerを付加する$( `Accept$h / `*/*^bl ) ◎ Append `Accept`/`*/*` to preflight’s header list.
- %予行 の`~header~list$rqに`~headerを付加する$( `Access-Control-Request-Method$h / %要請 の`~method$rq ) ◎ Append `Access-Control-Request-Method`/request’s method to preflight’s header list.
- %~header~list ~LET `~CORS非安全な要請~header名たち$( %要請 の`~header~list$rq ) ◎ Let headers be the CORS-unsafe request-header names with request’s header list.
-
~IF[ %~header~list は`空$でない ]: ◎ If headers is not empty, then:
- %値 ~LET %~header~list 内の各~itemを順に, `,^bl で区切って連結した結果 ◎ Let value be the items in headers separated from each other by `,`.
- %予行 の`~header~list$rqに`~headerを付加する$( `Access-Control-Request-Headers$h / %値 ) ◎ Append `Access-Control-Request-Headers`/value to preflight’s header list.
注記: ここで`~headerを結合する$を利用しないのは意図的である。 これは[ `2C^X `20^X ]並びによる仕方で実装されてはいないので — 功罪はあれど。 ◎ This intentionally does not use combine, as 0x20 following 0x2C is not the way this was implemented, for better or worse.
- %予行~fetch~params ~LET 新たな`~fetch~params$ — その ⇒# `要請$fP ~SET %予行 ◎ ↓
- %応答 ~LET `~HTTP~network-or-cache~fetch$( %予行~fetch~params ) ◎ Let response be the result of running HTTP-network-or-cache fetch given a new fetch params whose request is preflight.
-
~IF[ `~CORS検査$( %要請, %応答 ) ~EQ `成功^i ]~AND[ %応答 の`状態s$rs は`~ok状態s$である ]: ◎ If a CORS check for request and response returns success and response’s status is an ok status, then:
注記: 正しい`資格証~mode$rqの利用を確保するため、 `~CORS検査$は, %予行 ではなく %要請 に対して行う。 ◎ The CORS check is done on request rather than preflight to ensure the correct credentials mode is used.
- %~methods ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Access-Control-Allow-Methods$h ) ◎ Let methods be the result of extracting header list values given `Access-Control-Allow-Methods` and response’s header list.
- %~header名たち ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Access-Control-Allow-Headers$h ) ◎ Let headerNames be the result of extracting header list values given `Access-Control-Allow-Headers` and response’s header list.
- ~IF[ %~methods ~EQ `失敗^i ]~OR[ %~header名たち ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If either methods or headerNames is failure, return a network error.
-
~IF[ %~methods ~EQ ~NULL ]~AND[ `~CORS予行~利用~flag$rq ~EQ ~T ] ⇒ %~methods ~SET %要請 の`~method$rqのみからなる新たな~list ◎ If methods is null and request’s use-CORS-preflight flag is set, then set methods to a new list containing request’s method.
注記: これにより、単に[ %要請 の`~CORS予行~利用~flag$rq ~EQ ~T ]であることに因り生じる`~CORS予行~fetch$も,~cacheされる。 ◎ This ensures that a CORS-preflight fetch that happened due to request’s use-CORS-preflight flag being set is cached.
- ~IF[ %要請 の`~method$rq ~NIN %~methods ]~AND[ %要請 の`~method$rqは`~CORS安全とされる~method$でない ]~AND[[ %要請 の`資格証~mode$rq ~EQ `include^l ]~OR[ `*^bl ~NIN %~methods ]] ⇒ ~RET `~network~error$ ◎ If request’s method is not in methods, request’s method is not a CORS-safelisted method, and request’s credentials mode is "include" or methods does not contain `*`, then return a network error.
-
%要請 の`~header~list$rq内の ~EACH( %~header ) に対し:
- ~IF[ %~header は %~header名たち 内のある名前を`名前に持つ~header$である ] ⇒ ~CONTINUE
- ~IF[ %~header は`~CORS非~wildcard要請~header名$を`名前に持つ~header$である ] ⇒ ~RET `~network~error$
- ~IF[ %要請 の`資格証~mode$rq ~EQ `include^l ]~OR[ `*^bl ~NIN %~header名たち ] ⇒ `~CORS非安全な要請~header名たち$( %要請 の`~header~list$rq ) 内の ~EACH( %非安全~header名 ) に対し ⇒ %~header名たち 内の ~EACH( %~header名 ) に対し ⇒ ~IF[ ( 非安全~header名, %~header ) は`~byte大小無視$で合致する ] ⇒ ~RET `~network~error$ ◎ For each unsafeName in the CORS-unsafe request-header names with request’s header list, if unsafeName is not a byte-case-insensitive match for an item in headerNames and request’s credentials mode is "include" or headerNames does not contain `*`, return a network error.
- %寿命 ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Access-Control-Max-Age$h ) ◎ Let max-age be the result of extracting header list values given `Access-Control-Max-Age` and response’s header list.
- ~IF[ %寿命 ~IN { `失敗^i, ~NULL } ] ⇒ %寿命 ~SET 5 ◎ If max-age is failure or null, then set max-age to 5.
- ~IF[ %寿命 ~GT 環境により課される`寿命$ccの上限 ] ⇒ %寿命 ~SET その上限 ◎ If max-age is greater than an imposed limit on max-age, then set max-age to the imposed limit.
- ~IF[ ~UAは`~CORS予行~cache$を供していない ] ⇒ ~RET %応答 ◎ If the user agent does not provide for a cache, then return response.
-
%~methods 内の ~EACH( %~method ) に対し:
- %~entryたち ~LET `~methodも合致している~cache~entry$( %要請, %~method )
- ~IF[ %~entryたち は空でない ] ⇒ %~entryたち を成す各~entryに対し ⇒ その`寿命$cc ~SET %寿命
- ~ELSE ⇒ `新たな~cache~entryを作成する$( %要請, %寿命, %~method, ~NULL )
-
%~header名たち 内の ~EACH( %~header名 ) に対し:
- %~entryたち ~LET `~header名も合致している~cache~entry$( %要請, %~header名 )
- ~IF[ %~entryたち ~NEQ ε ] ⇒ %~entryたち を成す各~entryに対し ⇒ その`寿命$cc ~SET %寿命
-
~ELSE ⇒ `新たな~cache~entryを作成する$( %要請, %寿命, ~NULL, %~header名 )
- ~RET %応答 ◎ Return response.
- ~ELSE ⇒ ~RET `~network~error$ ◎ Otherwise, return a network error.
4.9. ~CORS予行~cache
各~UAは、 `~CORS予行~cache@ を持つ — それは、 0 個以上の`~cache~entry$からなる`~list$である。 ◎ A user agent has an associated CORS-preflight cache. A CORS-preflight cache is a list of cache entries.
各 `~cache~entry@ は、次に挙げるものからなる: ◎ A cache entry consists of:
- `~key@cc — `~network区分~key$ ◎ key (a network partition key)
- `~byte直列化した生成元@cc — `~byte列$ ◎ byte-serialized origin (a byte sequence)
- `~URL@cc — `~URL$ ◎ URL (a URL)
- `寿命@cc — 秒数 ◎ max-age (a number of seconds)
- `資格証の有無@cc — 次のいずれか ⇒# `有り^i, `無し^i ◎ credentials (a boolean)
- `~method@cc — 次のいずれか ⇒# ~NULL, `*^bl, `~method$ ◎ method (null, `*`, or a method)
- `~header名@cc — 次のいずれか ⇒# ~NULL, `*^bl, `~header$の`名前$hd ◎ header name (null, `*`, or a header name)
【 `~method$ccと`~header名$ccは,両立しない~fieldであり、常に,一方は ~NULL, 他方は非 ~NULL になる。 】
`~cache~entry$は、格納されてから`寿命$ccに指定された秒数だけ過ぎた時点で,除去するモノトスル — その時点が来る前に除去してもヨイ。 ◎ Cache entries must be removed after the seconds specified in their max-age field have passed since storing the entry. Cache entries may be removed before that moment arrives.
`新たな~cache~entryを作成する@ ときは、所与の ( %要請, %寿命, %~method, %~header名 ) に対し ⇒ `~CORS予行~cache$に[ 次のように初期化された,新たな`~cache~entry$ ]を`付加する$ ⇒# `~key$cc ~SET `~network区分~keyを決定する$( %要請 ), `~byte直列化した生成元$cc ~SET `要請の生成元を~byte直列化する$( %要請 ), `~URL$cc ~SET %要請 の`現在の~URL$rq, `寿命$cc ~SET %寿命, `資格証の有無$cc ~SET [%要請 の`資格証~mode$rq ~EQ `include^l ならば `有り^i / ~ELSE_ `無し^i ], `~method$cc ~SET %~method, `~header名$cc ~SET %~header名 ◎ To create a new cache entry, given request, max-age, method, and headerName, run these steps: ◎ Let entry be a cache entry, initialized as follows: ◎ key • The result of determining the network partition key given request byte-serialized origin • The result of byte-serializing a request origin with request URL • request’s current URL max-age • max-age credentials • True if request’s credentials mode is "include", and false otherwise method • method header name • headerName ◎ Append entry to the user agent’s CORS-preflight cache.
`~cache~entryを消去する@ ときは、所与の ( %要請 ) に対し:
-
~UAの`~CORS予行~cache$から,次をすべて満たす`~cache~entry$をすべて除去する:
- `~key$cc ~EQ `~network区分~keyを決定する$( %要請 )
- `~byte直列化した生成元$cc ~EQ `要請の生成元を~byte直列化する$( %要請 )
- `~URL$cc ~EQ %要請 の`現在の~URL$rq
次をすべて満たす`~cache~entry$は、 %要請 に `~cache合致する@ とされる: ◎ There is a cache entry match for a cache entry entry with request if\
- `~key$cc ~EQ `~network区分~keyを決定する$( %要請 ) ◎ entry’s key is the result of determining the network partition key given request,
- `~byte直列化した生成元$cc ~EQ `要請の生成元を~byte直列化する$( %要請 ) ◎ entry’s byte-serialized origin is the result of byte-serializing a request origin with request,\
- `~URL$cc ~EQ %要請 の`現在の~URL$rq ◎ entry’s URL is request’s current URL,\
- [ `資格証の有無$cc ~EQ `有り^i ]~OR[[ `資格証の有無$cc ~EQ `無し^i ]~AND[ %要請 の`資格証~mode$rq ~NEQ `include^l ]] ◎ and one of • entry’s credentials is true • entry’s credentials is false and request’s credentials mode is not "include". is true.
`~methodも合致している~cache~entry@ は、所与の ( %要請, %~method ) に対し,~UAの`~CORS予行~cache$内にある,次を満たす`~cache~entry$たちからなる集合を返す ⇒ [ %要請 に`~cache合致する$ ]~AND[ `~method$cc ~IN { %~method, `*^bl } ] ◎ There is a method cache entry match for method using request when there is a cache entry in the user agent’s CORS-preflight cache for which there is a cache entry match with request and its method is method or `*`.
【† 原文からは、該当する~entryは高々 1 個のように解釈できそうだが,複数あり得るかもしれない — はっきりしないので、この用語を利用している箇所も含め,複数あり得るとみなして訳している。 次の用語も同様。 】
`~header名も合致している~cache~entry@ は、所与の ( %要請, %~header名 ) に対し,~UAの`~CORS予行~cache$内にある,次を満たす`~cache~entry$たちからなる集合を返す ⇒ [ %要請 に`~cache合致する$ ]~AND[ ( ~entryの`~header名$cc %名前, %~header名 ) は次のいずれかを満たす ]: ◎ There is a header-name cache entry match for headerName using request when there is a cache entry in the user agent’s CORS-preflight cache for which there is a cache entry match with request and\
- %名前 は %~header名 に`~byte大小無視$で合致する
- [ %名前 ~EQ `*^bl ]~AND[ %~header名 は`~CORS非~wildcard要請~header名$でない ]
4.10. ~CORS検査
`~CORS検査@ は、所与の ( %要請, %応答 ) に対し,次を走らす: ◎ To perform a CORS check for a request and response, run these steps:
- %生成元 ~LET `~header~listから値を取得する$( %応答 の`~header~list$rs, `Access-Control-Allow-Origin$h ) ◎ Let origin be the result of getting `Access-Control-Allow-Origin` from response’s header list.
-
~IF[ %生成元 ~EQ ~NULL ] ⇒ ~RET `失敗^i ◎ If origin is null, then return failure.
注記: ~NULL は `null^bl でないことに注意。 ◎ Null is not `null`.
- ~IF[ %要請 の`資格証~mode$rq ~NEQ `include^l ]~AND[ %生成元 ~EQ `*^bl ] ⇒ ~RET `成功^i ◎ If request’s credentials mode is not "include" and origin is `*`, then return success.
- ~IF[ `要請の生成元を~byte直列化する$( %要請 ) ~NEQ %生成元 ] ⇒ ~RET `失敗^i ◎ If the result of byte-serializing a request origin with request is not origin, then return failure.
- ~IF[ %要請 の`資格証~mode$rq ~NEQ `include^l ] ⇒ ~RET `成功^i ◎ If request’s credentials mode is not "include", then return success.
- %資格証 ~LET `~header~listから値を取得する$( %応答 の`~header~list$rs, `Access-Control-Allow-Credentials$h ) ◎ Let credentials be the result of getting `Access-Control-Allow-Credentials` from response’s header list.
- ~IF[ %資格証 ~EQ `true^bl ] ⇒ ~RET `成功^i ◎ If credentials is `true`, then return success.
- ~RET `失敗^i ◎ Return failure.
4.11. ~TAO検査
【 ~TAOは `Timing-Allow-Origin$h (計時を許容する生成元)の略称。 】
`~TAO検査@ を遂行するときは、所与の ( %要請, %応答 ) に対し,次の手続きを走らす: ◎ To perform a TAO check for a request and response, run these steps:
- ~IF[ %要請 の`計時許容に失敗した~flag$rq ~EQ ~T ] ⇒ ~RET `失敗^i ◎ If request’s timing allow failed flag is set, then return failure.
- ~IF[ %要請 の`応答~tainting$rq ~EQ `basic^l ] ⇒ ~RET `成功^i ◎ If request’s response tainting is "basic", then return success.
- %値~list ~LET `~header~listから値を取得して復号して分割する$( %応答 の`~header~list$rs, `Timing-Allow-Origin$h ) ◎ Let values be the result of getting, decoding, and splitting `Timing-Allow-Origin` from response’s header list.
- ~IF[ `*^l ~IN %値~list ] ⇒ ~RET `成功^i ◎ If values contains "*", then return success.
- ~IF[ `要請の生成元を直列化する$( %要請 ) ~IN %値~list ] ⇒ ~RET `成功^i ◎ If values contains the result of serializing a request origin with request, then return success.
- ~RET `失敗^i ◎ Return failure.
5. ~fetch~API
`fetch()$m ~methodは、資源を`~fetch$するための,比較的 低~levelな~APIであり、 `XMLHttpRequest$I より少しばかり土台を受持つ — 現時点では、いつ要請の進展(応答の進展ではなく)が来たかを報告する機能を欠いているが。 ◎ The fetch() method is relatively low-level API for fetching resources. It covers slightly more ground than XMLHttpRequest, although it is currently lacking when it comes to request progression (not response progression).
`fetch()$m ~methodは、ごく率直に,資源を`~fetch$した上で その内容を `Blob$I として抽出する: ◎ The fetch() method makes it quite straightforward to fetch a resource and extract its contents as a Blob:
fetch(`/music/pk/altes-kamuffel.flac^l) .then(%res => %res.blob()).then(%playBlob);
【
記法
“%args => %code
”
は、 %args を入力に %code を走らす無名~関数(
arrow function
)。
】
特定0の応答~headerの~logをとりたいだけなら: ◎ If you just care to log a particular response header:
fetch(`/^l, {method:`HEAD^l}) .then(%res => log(%res.headers.get(`strict-transport-security^l)));
特定0の応答~headerを検査して,非同一-生成元の資源を成す応答を処理したいなら: ◎ If you want to check a particular response header and then process the response of a cross-origin resource:
fetch(`https://pk.example/berlin-calling.json^l, {mode:`cors^l}) .then(%res => { if(%res.headers.get(`content-type^l) && ( %res.headers.get(`content-type^l) .toLowerCase() .indexOf(`application/json^l) >= 0 ) ) { return %res.json(); } else { throw new TypeError(); } }).then(processJSON);
URL ~query~parameterを~~利用したいなら: ◎ If you want to work with URL query parameters:
var %url = new URL(`https://geo.example.org/api^l), %params = {lat:35.696233, long:139.570431}; Object.keys(%params).forEach( %key => %url.searchParams.append(%key, params[%key]) ); fetch(%url).then(/* … */);
本体~dataを漸進的に受信したいなら: ◎ If you want to receive the body data progressively:
function consume(%reader) { var %total = 0 return pump(); function pump() { return %reader.read().then(({%done, %value}) => { if (%done) { return; } %total += %value.byteLength; log(``^受信した~byte数 ${%value.byteLength} (総~byte数 ${%total} )``^ ); return pump(); }) } } fetch(`/music/pk/altes-kamuffel.flac^l) .then(%res => consume(%res.body.getReader())) .then( () => log( `~memory内に全部~~貯めこむことなく,本体~全体を消費できました!^l )) .catch(%e => log(`何かまずいことが起きました: ^l + %e))
5.1. `Headers^I ~class
typedef ( `sequence$<`sequence$<`ByteString$>> or `record$<`ByteString$, `ByteString$> ) `HeadersInit@I; [`Exposed$=(Window,Worker)] interface `Headers@I { `Headers$mc(optional `HeadersInit$I %init); `undefined$ `append$m(`ByteString$ %name, `ByteString$ %value); `undefined$ `delete$m(`ByteString$ %name); `ByteString$? `get$m(`ByteString$ %name); `boolean$ `has$m(`ByteString$ %name); `undefined$ `set$m(`ByteString$ %name, `ByteString$ %value); `iterable$m<`ByteString$, `ByteString$>; };
注記: `~header~list$と違って、 `Headers$I ~objは,複数個の `Set-Cookie$h `~header$を表現できない。 `Set-Cookie^h ~headerは,他のすべての~headerと違って【複数個の`~field行l$を一つに】結合できないので、これは ある面で問題になり得るが、この~headerは ~client側~JSには公開されないので,これは受容-可能な妥協点と判断される。 実装は、`~header~list$用であっても — `Set-Cookie^h ~header用の~data構造も~supportする限り — より効率的な `Headers$I ~obj表現を選ぶこともできる。 ◎ Unlike a header list, a Headers object cannot represent more than one `Set-Cookie` header. In a way this is problematic as unlike all other headers `Set-Cookie` headers cannot be combined, but since `Set-Cookie` headers are not exposed to client-side JavaScript this is deemed an acceptable compromise. Implementations could choose the more efficient Headers object representation even for a header list, as long as they also support an associated data structure for `Set-Cookie` headers.
各 `Headers$I ~objには,次に挙げるものが結付けられる: ◎ ↓
- `~header~list@Hl(初期~時は空)
- `~header~list$。 ◎ A Headers object has an associated header list (a header list), which is initially empty.\
- 注記: これは、何か他の~objの`~header~list$を指すこともある。 例えば `Request$I ~objの`要請$のそれを指すなど。 ◎ This can be a pointer to the header list of something else, e.g., of a request as demonstrated by Request objects.
- `~guard@Hl(初期~時は `none^l )
- `~Headers用の~guard$。 ◎ A Headers object also has an associated guard, which is a headers guard.
- `~Headers用の~guard@ は、次のいずれかである ⇒# `immutable^l, `request^l, `request-no-cors^l, `response^l, `none^l ◎ A headers guard is "immutable", "request", "request-no-cors", "response" or "none".
- %headers = `new Headers([init])$m
- 新たな `Headers$I ~objを作成する。 %init を利用して,その内部の~header~listを埋めれる — 下の例のように。 ◎ Creates a new Headers object. init can be used to fill its internal header list, as per the example below.
-
const %meta = { "Content-Type": "text/xml", "Breaking-Bad": "<3" }; new Headers(%meta); /* 上の~codeは、次と等価になる: ◎ The above is equivalent to */ const %meta2 = [ [ "Content-Type", "text/xml" ], [ "Breaking-Bad", "<3" ] ]; new Headers(%meta2);
- %headers . `append(name, value)$m
- %headers に~headerを付加する。 ◎ Appends a header to headers.
- %headers . `delete(name)$m
- %headers から~headerを除去する。 ◎ Removes a header from headers.
- %headers . `get(name)$m
- 名前に %name を伴うすべての~headerの値を[ ~commaと~space ]で分離した文字列として返す。 ◎ Returns as a string the values of all headers whose name is name, separated by a comma and a space.
- %headers . `has(name)$m
- 名前に %name を伴う~headerは在るかどうかを返す。 ◎ Returns whether there is a header whose name is name.
- %headers . `set(name, value)$m
- 名前に %name を伴う~headerのうち,最初の~headerの値を置換して残りは除去する。 ◎ Replaces the value of the first header whose name is name with value and removes any remaining headers whose name is name.
- for(const [%name, %value] of %headers)
- %headers は反復できる( `iterable$m )。 ◎ headers can be iterated over.
`~Headers~objを作成する@ ときは、所与の ( `~header~list$ %~header~list, `~Headers用の~guard$ %~guard, ~Realm %~realm ) に対し,次を走らす:
- %~Headers~obj ~LET %~realm に属する`新たな$ `Headers$I ~obj
- %~Headers~obj の ⇒# `~header~list$Hl ~SET %~header~list, `~guard$Hl ~SET %~guard
- ~RET %~Headers~obj
【 この~algoは、他所を簡潔に述べるために,この訳に導入している。 】
`~guardで検査する@ ときは、所与の ( %名前, %値, `~guard$Hl %~guard ) に対し,次を走らす:
【 この~algoは、共通な記述を集約するため,この訳に導入したものである。 】
- ~IF[ %名前 は`名前$hdでない ]~OR[ %値 は`値$hdでない ] ⇒ ~THROW `TypeError$E
-
%~guard に応じて:
- `immutable^l ⇒ ~THROW `TypeError$E
- `request^l ⇒ ~IF[ %名前 は`禁止~header名$である ] ⇒ ~RET `不合格^i
- `response^l ⇒ ~IF[ %名前 は`禁止~応答~header名$である ] ⇒ ~RET `不合格^i
- `request-no-cors^l ⇒ ~RET `場合によっては合格^i
- ~RET `合格^i
`Headers$I ~obj %headers に~pair ( `名前$hd %名前 / `値$hd %値 ) を `付加する@Hl ときは、次を走らす: ◎ To append a name/value name/value pair to a Headers object (headers), run these steps:
- %値 ~SET `値を正規化する$( %値 ) ◎ Normalize value.
-
`~guardで検査する$( %名前, %値, %headers の`~guard$Hl ) の結果に応じて:
- `不合格^i ⇒ ~RET
-
`場合によっては合格^i:
- %一時的な値 ~LET `~header~listから値を取得する$( %headers の`~header~list$Hl, %名前 )
- ~IF[ %一時的な値 ~EQ ~NULL ] ⇒ %一時的な値 ~SET %値
- ~ELSE ⇒ %一時的な値 に次を順に付加する ⇒# `2C^X, `20^X, %値
- ~IF[ ( %名前 / %一時的~値 ) は`~CORSなしで安全とされる要請~header$でない ] ⇒ ~RET
- %headers の`~header~list$Hlに`~headerを付加する$( %名前 / %値 ) ◎ Append name/value to headers’s header list.
- ~IF[ %headers の`~guard$Hl ~EQ `request-no-cors^l ] ⇒ %headers から`特権的~CORSなし要請~headerを除去する$ ◎ If headers’s guard is "request-no-cors", then remove privileged no-CORS request headers from headers.
`Headers$I ~obj %headers を,所与の~obj %~obj で `埋める@Hl ときは、次を走らす: ◎ To fill a Headers object headers with a given object object, run these steps:
-
~IF[ %~obj は~IDL`連列~型$である ]: ◎ ↓
-
%~obj 内の ~EACH( %~header ) に対し: ◎ If object is a sequence, then for each header in object:
- ~IF[ %~header 内の~item数 ~NEQ 2 ] ⇒ ~THROW `TypeError$E ◎ If header does not contain exactly two items, then throw a TypeError.
- %headers に ( %~header の 1 個目の~item / %~header の 2 個目の~item ) を`付加する$Hl ◎ Append header’s first item/header’s second item to headers.
-
- ~ELSE( %~obj は~IDL`~record型$である ) ⇒ %~obj 内の ~EACH( %~key → %値 ) に対し ⇒ %headers に ( %~key / %値 ) を`付加する$Hl ◎ Otherwise, object is a record, then for each key → value in object, append key/value to headers.
`Headers$I ~obj %headers から `特権的~CORSなし要請~headerを除去する@ ときは、次を走らす: ◎ To remove privileged no-CORS request headers from a Headers object (headers), run these steps:
- `特権的~CORSなし要請~header名$を成す ~EACH( %~header名 ) に対し ⇒ %headers の`~header~list$Hlから`~headerを削除する$( %~header名 ) ◎ For each headerName of privileged no-CORS request-header names: • Delete headerName from headers’s header list.
注記: これは、 %headers が特権的でない~codeにより改変されたときに~callされる。 ◎ This is called when headers are modified by unprivileged code.
`new Headers(init)@m 構築子~手続きは: ◎ The new Headers(init) constructor steps are:
- コレの`~guard$Hl ~SET `none^l ◎ Set this’s guard to "none".
- ~IF[ %init ~NEQ ε ] ⇒ コレ を %init で`埋める$Hl ◎ If init is given, then fill this with init.
`delete(name)@m ~method~手続きは: ◎ The delete(name) method steps are:
-
`~guardで検査する$( %name, `valid-value^bl, コレの`~guard$Hl ) の結果に応じて:
- `不合格^i ⇒ ~RET
- `場合によっては合格^i ⇒ ~IF[ %name は`~CORSなしで安全とされる要請~header名$でない ]~AND[ %name は`特権的~CORSなし要請~header名$でない ] ⇒ ~RET
- ~IF[ コレの`~header~list$Hl内に[ %name を`名前に持つ~header$ ]は無い ] ⇒ ~RET ◎ If this’s header list does not contain name, then return.
- コレの`~header~list$Hlから`~headerを削除する$( %name ) ◎ Delete name from this’s header list.
- ~IF[ コレの`~guard$Hl ~EQ `request-no-cors^l ] ⇒ コレから`特権的~CORSなし要請~headerを除去する$ ◎ If this’s guard is "request-no-cors", then remove privileged no-CORS request headers from this.
`get(name)@m ~method~手続きは: ◎ The get(name) method steps are:
- ~IF[ %name は`名前$hdでない ] ⇒ ~THROW `TypeError$E ◎ If name is not a name, then throw a TypeError.
- ~RET `~header~listから値を取得する$( コレの`~header~list$Hl, %name ) ◎ Return the result of getting name from this’s header list.
`has(name)@m ~method~手続きは: ◎ The has(name) method steps are:
- ~IF[ %name は`名前$hdでない ] ⇒ ~THROW `TypeError$E ◎ If name is not a name, then throw a TypeError.
- ~RET コレの`~header~list$Hl内に[ %name を`名前に持つ~header$ ]は[ 在るならば ~T / 無いならば ~F ] ◎ Return true if this’s header list contains name; otherwise false.
`set(name, value)@m ~method~手続きは: ◎ The set(name, value) method steps are:
- %value ~SET `値を正規化する$( %value ) ◎ Normalize value.
-
`~guardで検査する$( %name, %value, コレの`~guard$Hl ) の結果に応じて:
- `不合格^i ⇒ ~RET
- `場合によっては合格^i ⇒ ~IF[ ( %name / %value ) は`~CORSなしで安全とされる要請~header$でない ] ⇒ ~RET
- コレの`~header~list$Hl内で`~headerを設定する$( %name / %value ) ◎ Set name/value in this’s header list.
- ~IF[ `~guard$Hl ~EQ `request-no-cors^l ] ⇒ コレから`特権的~CORSなし要請~headerを除去する$ ◎ If this’s guard is "request-no-cors", then remove privileged no-CORS request headers from this.
5.2. `BodyInit^I 共用体
typedef ( `Blob$I or `BufferSource$I or `FormData$I or `URLSearchParams$I or `USVString$ ) `XMLHttpRequestBodyInit@I typedef (`ReadableStream$I or `XMLHttpRequestBodyInit$I) `BodyInit@I;
`本体と内容~型を安全に抽出する@ ときは、所与の ( %~obj ) に対し,次を走らす — この手続きは ( `本体$, `Content-Type$h 用の`値$hd ) の組を返す: ◎ To safely extract a body and a `Content-Type` value from object, run these steps:
- ~IF[ %~obj は `ReadableStream$I ~objである ] ⇒ ~Assert: %~obj は次を満たしていない ⇒ [ `妨げられている$RS ]~OR[ `~lockされている$RS ] ◎ If object is a ReadableStream object, then: • Assert: object is neither disturbed nor locked.
- ~RET `本体と内容~型を抽出する$( %~obj ) ◎ Return the results of extracting object.
注記: `本体と内容~型を安全に抽出する$演算は、例外を投出しないことが保証される,`本体と内容~型を抽出する$演算である。 ◎ The safely extract operation is a subset of the extract operation that is guaranteed to not throw an exception.
`本体と内容~型を抽出する@ ときは、所与の ( %~obj, %~keepalive~flag ~IN { `~keepalive@i, ε }(省略時は ε ) 【!boolean keepalive (default false)】 ) に対し,次を走らす — この手続きは ( `本体$, `Content-Type$h 用の`値$hd ) の組を返す: ◎ To extract a body and a `Content-Type` value from object, with an optional boolean keepalive (default false), run these steps:
- %~stream ~LET %~obj に応じて ⇒# `ReadableStream$I ~objであるならば %~obj / ~ELSE_ `ReadableStream$I を`作成する$RS() ◎ Let stream be object if object is a ReadableStream object; otherwise the result of creating a ReadableStream.
- %内容~型 ~LET ~NULL ◎ Let Content-Type be null.
- %動作 ~LET ~NULL ◎ Let action be null.
- %~source ~LET %~obj に応じて ⇒# `ReadableStream$I ~objであるならば ~NULL / ~ELSE_ %~obj ◎ Let source be null if object is a ReadableStream object; otherwise object.
-
%~obj に応じて: ◎ Switch on object:
- `Blob$I
-
- %動作 ~SET 次を走らす動作 ⇒ ~RET %~obj を読取った結果† ◎ Set action to an action that reads object.
- ~IF[ %~obj の `type$mF 属性 ~NEQ 空~byte列 ] ⇒ %内容~型 ~SET その属性~値 ◎ If object’s type attribute is not the empty byte sequence, set Content-Type to its value.
【† 明確には指定されていないが、以降の処理は, `FILEAPI$r に定義される`~streamを取得する$ ~algoと同じ結果になると見受けられる。 】
- `~byte列$ ◎ byte sequence
-
- %動作 ~SET 次を走らす動作 ⇒ ~RET %~obj ◎ Set action to an action that returns object.
- `BufferSource$I
-
- %動作 ~SET 次を走らす動作 ⇒ ~RET %~obj が保持している~byte列の`複製を取得する$ ◎ Set action to an action that returns a copy of the bytes held by object.
- `FormData$I
-
- %動作 ~SET 次を走らす動作 ⇒ ~RET `~mp_form_dataとして符号化する$( %~obj, `~UTF-8$enc ) ◎ Set action to an action that runs the multipart/form-data encoding algorithm, with object as form data set and with UTF-8 as the explicit character encoding.
- %内容~型 ~SET `multipart/form-data; boundary=^bl ◎ Set Content-Type to `multipart/form-data; boundary=`,\
- %内容~型 に次を付加する ⇒ %動作 により生成されることになる `~mp_form_data境界~文字列$ ◎ followed by the multipart/form-data boundary string generated by the multipart/form-data encoding algorithm.
- `URLSearchParams$I
-
- %動作 ~SET 次を走らす動作 ⇒ ~RET `~form_urlencoded直列化器$( %~obj の`名値~pair~list$ ) ◎ Set action to an action that runs the application/x-www-form-urlencoded serializer with object’s list.
- %内容~型 ~SET `application/x-www-form-urlencoded;charset=UTF-8^bl ◎ Set Content-Type to `application/x-www-form-urlencoded;charset=UTF-8`.
- `~scalar値~文字列$ ◎ scalar value string
-
- %動作 ~SET 次を走らす動作 ⇒ ~RET `~UTF-8符号化する$( %~obj ) ◎ Set action to an action that runs UTF-8 encode on object.
- %内容~型 ~SET `text/plain;charset=UTF-8^bl ◎ Set Content-Type to `text/plain;charset=UTF-8`.
- `ReadableStream$I
-
- ~IF[ %~keepalive~flag ~NEQ ε ]~OR[ %~obj は`妨げられている$RS ]~OR[ %~obj は`~lockされている$RS ] ⇒ ~THROW `TypeError$E ◎ If keepalive is true, then throw a TypeError. ◎ If object is disturbed or locked, then throw a TypeError.
-
~IF[ %動作 ~NEQ ~NULL ] ⇒ 次に従う下で %動作 を`並列的$に走らす: ◎ If action is non-null, run action in parallel:
- 【 %動作 の結果から】 1 個以上の~byte %~byte列 が可用になるたびに ⇒ %~stream に`~chunkを~enqueueする$RS( %~byte列 を包含している `ArrayBuffer$I を包装している `Uint8Array$I ) ◎ Whenever one or more bytes are available and stream is not errored, enqueue a Uint8Array wrapping an ArrayBuffer containing the available bytes into stream.
- 前項により %~stream が`~errorした$RSときは ⇒ この段を終える 【この場合、次項を飛ばしても同じ結果になると見受けられる。】 ◎ ↑
- %動作 を走らせ終えたときは ⇒ %~stream を`~closeする$RS() ◎ When running action is done, close stream.
- %本体 ~LET 次のようにされた新たな`本体$ ⇒# `~stream$bd ~SET %~stream; `~source$bd ~SET %~source ◎ Let body be a body whose stream is stream and whose source is source.
- ~RET ( %本体, %内容~型 ) ◎ Return body and Content-Type.
5.3. `Body^I ~mixin
interface mixin `Body@I { readonly attribute `ReadableStream$I? `body$m; readonly attribute `boolean$ `bodyUsed$m; [`NewObject$] `Promise$<`ArrayBuffer$I> `arrayBuffer$m(); [`NewObject$] `Promise$<`Blob$I> `blob$m(); [`NewObject$] `Promise$<`FormData$I> `formData$m(); [`NewObject$] `Promise$<`any$> `json$m(); [`NewObject$] `Promise$<`USVString$> `text$m(); };
注記: ~HTMLなど,~network層に依存させたくない内容形式が、ここで公開されることにはならないであろう。 むしろ、~HTML構文解析器~APIが,~streamを受容するようになるであろう。 【参考】 【~HTML 課題 #2993】 ◎ Formats you would not want a network layer to be dependent upon, such as HTML, will likely not be exposed here. Rather, an HTML parser API might accept a stream in due course.
`Body$I ~interface~mixinを内包している各~objには、次に挙げるものが結付けられる:
- `~MIME型@Bd
- [ `失敗^i /`~MIME型$ ]を返す~algo。
- `本体@Bd
- ~NULL または `本体$。
`Body$I ~interface~mixinを内包している~objは、次を満たすとき, `利用-不能@Bd という ⇒ [ その`本体$Bd %本体 ~NEQ ~NULL ]~AND[ %本体 の`~stream$bdは、`妨げられている$RSか`~lockされている$RS ] ◎ An object including the Body interface mixin is said to be unusable if its body is non-null and its body’s stream is disturbed or locked.
- %requestOrResponse . `body$m
- %requestOrResponse の本体を `ReadableStream$I として返す。 ◎ Returns requestOrResponse’s body as ReadableStream.
- %requestOrResponse . `bodyUsed$m
- %requestOrResponse の本体は読取られたかどうかを返す。 ◎ Returns whether requestOrResponse’s body has been read from.
- %requestOrResponse . `arrayBuffer()$m
- %requestOrResponse の本体で — `ArrayBuffer$I として — 充足される~promiseを返す。 ◎ Returns a promise fulfilled with requestOrResponse’s body as ArrayBuffer.
- %requestOrResponse . `blob()$m
- %requestOrResponse の本体で — `Blob$I として — 充足される~promiseを返す。 ◎ Returns a promise fulfilled with requestOrResponse’s body as Blob.
- %requestOrResponse . `formData()$m
- %requestOrResponse の本体で — `FormData$I として — 充足される~promiseを返す。 ◎ Returns a promise fulfilled with requestOrResponse’s body as FormData.
- %requestOrResponse . `json()$m
- %requestOrResponse の本体で — ~JSONとして構文解析されたものとして — 充足される~promiseを返す。 ◎ Returns a promise fulfilled with requestOrResponse’s body parsed as JSON.
- %requestOrResponse . `text()$m
- %requestOrResponse の本体で — 文字列として — 充足される~promiseを返す。 ◎ Returns a promise fulfilled with requestOrResponse’s body as string.
`~dataを梱包する@ ~algoは、所与の ( %~byte列, %型, %~MIME型 ) に対し, %型 に応じて次を走らす: ◎ The package data algorithm, given bytes, type, and a mimeType, switches on type, and runs the associated steps:
- `ArrayBuffer^i
- ~RET %~byte列 を内容とする新たな `ArrayBuffer$I ◎ Return a new ArrayBuffer whose contents are bytes.
- 注記: `ArrayBuffer^I を割振るときには、 `RangeError$E が投出され得る。 ◎ Allocating an ArrayBuffer can throw a RangeError.
- `Blob^i
- ~RET 次のようにされた `Blob$I ⇒# %~byte列 を内容とする, `type$mF 属性 ~SET %~MIME型 ◎ Return a Blob whose contents are bytes and type attribute is mimeType.
- `FormData^i
-
%~MIME型 の`~essence$に応じて: ◎ ↓
- `multipart/form-data^l ◎ If mimeType’s essence is "multipart/form-data", then:
-
-
`Returning Values from Forms: multipart/form-data^cite `RFC7578$r に則って、 ( %~MIME型 の `boundary^bl ~parameterの値 ) を与える下で, %~byte列 を構文解析する — それにより得られた各 部位 %部位 に対しては、[ %部位 の中の `Content-Disposition^h ~headerが `filename^bl ~parameterを包含するかどうかに応じて,次で与えられる値 ]を値とする`~entry$xhrに構文解析するモノトスル: ◎ Parse bytes, using the value of the `boundary` parameter from mimeType, per the rules set forth in Returning Values from Forms: multipart/form-data. [RFC7578]
- 包含する場合
-
次のようにされた `File$I ~obj:
- その内容 ~SET %部位 の内容
- `name$mF 属性の値 ~SET `filename^bl ~parameterの値
- `type$mF 属性の値 ~SET %部位 内に `Content-Type$h ~headerが[ あれば その~header値 / なければ `text/plain^bl ( `RFC7578$r § 4.4 に定義される既定) ]
- 包含しない場合
- `~BOMはそのままに~UTF-8復号する$( %部位 の内容 ) の結果 ◎ Each part whose `Content-Disposition` header does not contain a `filename` parameter must be parsed into an entry whose value is the UTF-8 decoded without BOM content of the part.\
- 注記: これは、[ `Content-Type$h ~header / `charset^bl ~parameter ]の有無やその値に関わらず行われる。 ◎ This is done regardless of the presence or the value of a `Content-Type` header and regardless of the presence or the value of a `charset` parameter.
注記: [ `Content-Disposition^h ~headerが `name^bl ~parameterを包含していて, その値は `_charset_^bl である ]ような部位も、他の部位と同様に構文解析される。 それは符号化法を変更することはない。 ◎ A part whose `Content-Disposition` header contains a `name` parameter whose value is `_charset_` is parsed like any other part. It does not change the encoding.
- ~IF[ 何らかの事由で,前~段が失敗した ] ⇒ ~THROW `TypeError$E ◎ If that fails for some reason, then throw a TypeError.
- ~RET [ `~entry$xhrの~list ~SET 構文解析した結果の`~entry$xhrたち ]にされた,新たな `FormData$I ~obj ◎ Return a new FormData object, appending each entry, resulting from the parsing operation, to entries.
課題: 上述は `multipart/form-data^bl に必要なものの~~概略であり、より詳細な構文解析~仕様が書かれることになる。 ~~協力を歓迎する。 ◎ The above is a rough approximation of what is needed for `multipart/form-data`, a more detailed parsing specification is to be written. Volunteers welcome.
-
- `application/x-www-form-urlencoded^l ◎ Otherwise, if mimeType’s essence is "application/x-www-form-urlencoded", then:
-
- %~entryたち ~LET `~form_urlencoded構文解析器$( %~byte列 ) ◎ Let entries be the result of parsing bytes.
- ~IF[ %~entryたち ~EQ `失敗^i ] ⇒ ~THROW `TypeError$E ◎ If entries is failure, then throw a TypeError.
- ~ELSE ⇒ ~RET 次のようにされた,新たな `FormData$I ~obj ⇒ `~entry$xhrの~list ~SET %~entryたち ◎ Return a new FormData object whose entries are entries.
- その他
- ~THROW `TypeError$E ◎ Otherwise, throw a TypeError.
- `JSON^i
- ~RET `~JSON~byte列を~JS値に構文解析する$( %~byte列 ) ◎ Return the result of running parse JSON from bytes on bytes.
- `text^i
- ~RET `~UTF-8復号する$( %~byte列 ) ◎ Return the result of running UTF-8 decode on bytes.
`本体を消費する@ ~algoは、所与の ( %~obj, %型 ) に対し,次を走らす: ◎ The consume body algorithm, given an object and type, runs these steps:
- ~IF[ %~obj は`利用-不能$Bdである ] ⇒ ~RET `TypeError$E で`却下される~promise$ ◎ If object is unusable, then return a promise rejected with a TypeError.
- %~promise ~LET 空な`~byte列$で`解決される~promise$ ◎ Let promise be a promise resolved with an empty byte sequence.
- ~IF[ %~obj の`本体$Bd ~NEQ ~NULL ] ⇒ %~promise ~SET `本体を~promiseとして全部的に読取る$( %~obj の`本体$Bd ) ◎ If object’s body is non-null, then set promise to the result of fully reading body as promise given object’s body.
- %手続き ~LET 次を走らす手続き ⇒ ~RET `~dataを梱包する$( 所与の最初の引数, %型, %~obj の`~MIME型$Bd() ) ◎ Let steps be to return the result of package data with the first argument given, type, and object’s MIME type.
- ~RET %~promise の`充足-時$には %手続き を遂行するようにした結果 ◎ Return the result of upon fulfillment of promise given steps.
5.4. `Request^I ~class
typedef (`Request$I or `USVString$) `RequestInfo@I;
[`Exposed$=(Window,Worker)]
interface `Request@I {
`Request$mc(`RequestInfo$I %input, optional `RequestInit$I %init = {});
readonly attribute `ByteString$ `method$m;
readonly attribute `USVString$ `url$m;
[`SameObject$] readonly attribute `Headers$I `headers$m;
readonly attribute `RequestDestination$I `destination$m;
readonly attribute `USVString$ `referrer$m;
readonly attribute `ReferrerPolicy$I `referrerPolicy$m;
readonly attribute `RequestMode$I `mode$m;
readonly attribute `RequestCredentials$I `credentials$m;
readonly attribute `RequestCache$I `cache$m;
readonly attribute `RequestRedirect$I `redirect$m;
readonly attribute `DOMString$ `integrity$m;
readonly attribute `boolean$ `keepalive$m;
readonly attribute `boolean$ `isReloadNavigation$m;
readonly attribute `boolean$ `isHistoryNavigation$m;
readonly attribute `AbortSignal$I `signal$m;
[`NewObject$] `Request$I `clone$m();
};
`Request$I includes `Body$I;
dictionary `RequestInit@I {
`ByteString$ `method@RqI;
`HeadersInit$I `headers@RqI;
`BodyInit$I? `body@RqI;
`USVString$ `referrer@RqI;
`ReferrerPolicy$I `referrerPolicy@RqI;
`RequestMode$I `mode@RqI;
`RequestCredentials$I `credentials@RqI;
`RequestCache$I `cache@RqI;
`RequestRedirect$I `redirect@RqI;
`DOMString$ `integrity@RqI;
`boolean$ `keepalive@RqI;
`AbortSignal$I? `signal@RqI;
`any$ `window@RqI; /*
~NULL にしか設定できない。
◎
can only be set to null
*/
};
enum `RequestDestination@I {
"", "audio", "audioworklet", "document", "embed", "font", "frame", "iframe", "image", "manifest", "object", "paintworklet", "report", "script", "sharedworker", "style", "track", "video", "worker", "xslt"
};
enum `RequestMode@I {
"navigate", "same-origin", "no-cors", "cors"
};
enum `RequestCredentials@I {
"omit", "same-origin", "include"
};
enum `RequestCache@I {
"default", "no-store", "reload", "no-cache", "force-cache", "only-if-cached"
};
enum `RequestRedirect@I {
"follow", "error", "manual"
};
注記: `serviceworker^l が `RequestDestination$I から省略されているのは、~JSからは観測し得ないからである。 それでも,実装は、`行先$rqとして それを~supportする必要がある。 `websocket^l が `RequestMode$I から省略されているのは、~JSからは観測し得ないからである。 ◎ "serviceworker" is omitted from RequestDestination as it cannot be observed from JavaScript. Implementations will still need to support it as a destination. "websocket" is omitted from RequestMode as it cannot be used nor observed from JavaScript.
各 `Request$I ~objには、次に挙げるものが結付けられる: ◎ ↓
- `要請@Rq
- `要請$。 ◎ A Request object has an associated request (a request).
- `~Headers@Rq
- ~NULL または `Headers$I ~obj — 初期~時は ~NULL 。 ◎ A Request object also has an associated headers (null or a Headers object), initially null.
- `通達@Rq
- ~NULL または `AbortSignal$I ~obj — 初期~時は ~NULL 。 ◎ A Request object has an associated signal (null or an AbortSignal object), initially null.
【 `~Headers$Rq, `通達$Rq は、どちらも, `Request$I ~objの作成-時に非 ~NULL に設定されることになる。 】
`Request$I ~objの`~MIME型$Bdは、次の結果を返す ⇒ `~header~listから~MIME型を抽出する$( ~objの`要請$Rqの`~header~list$rq ) ◎ A Request object’s MIME type is to return the result of extracting a MIME type from its request’s header list.
`Request$I ~objの`本体$Bdは、その`要請$Rqの`本体$rqである。 ◎ A Request object’s body is its request’s body.
- %request = `new Request$m(%input [, %init ])
- 新たな `Request$I ~obj %request を返す — その `url$m ~propは、 %input に応じて[ 文字列ならば %input / `Request$I ~objであるならば %input の `url$m ]にされる。 ◎ Returns a new request whose url property is input if input is a string, and input’s url if input is a Request object.
-
%init 引数は、~objであり,次に挙げる~propを設定できる: ◎ The init argument is an object whose properties can be set as follows:
- `method$RqI
- %request の `method$m を設定する文字列。 ◎ A string to set request’s method.
- `headers$RqI
- %request の `headers$m 用の `Headers$I ~objを設定する値を次のいずれかとして与える ⇒# ~obj~literal【~JS Object 値】, それぞれが 2 個の~itemからなる配列たちが成す配列 ◎ A Headers object, an object literal, or an array of two-item arrays to set request’s headers.
- `body$RqI
- %request の`本体$rqを設定する[ `BodyInit$I ~obj, または ~NULL ]。 ◎ A BodyInit object or null to set request’s body.
- `referrer$RqI
- %request の`~referrer$rqを設定する文字列 — 次のいずれか ⇒# 同一-生成元~URL, `about:client^l, 空~文字列 ◎ A string whose value is a same-origin URL, "about:client", or the empty string, to set request’s referrer.
- `referrerPolicy$RqI
- %request の `referrerPolicy$m を設定する`~referrer施策$。 ◎ A referrer policy to set request’s referrerPolicy.
- `mode$RqI
- %request の `mode$m を設定する文字列 — 要請は次のどちらになるかを指示する ⇒# ~CORSを利用する/ 同一-生成元~URLに制約される ◎ A string to indicate whether the request will use CORS, or will be restricted to same-origin URLs. Sets request’s mode.\
- %input に文字列が与えられた場合の既定は `cors^l になる。 ◎ If input is a string, it defaults to "cors".
- `credentials$RqI
-
%request の `credentials$m を設定する文字列 — 次の表のどの行が適用されるかを指示する:
◎ A string indicating whether credentials will be sent with the request always, never, or only when sent to a same-origin URL\ — as well as whether any credentials sent back in the response will be used always, never, or only when received from a same-origin URL. Sets request’s credentials.\要請に伴う資格証は,いつ送信されるか 返信された応答~内に資格証がある場合,いつ利用されるか 常に送信される 常に利用される 決して送信されない 決して利用されない 同一-生成元~URLに限り送信される 同一-生成元~URLから受信した場合に限り利用される - %input に文字列が与えられた場合の既定は `same-origin^l になる。 ◎ If input is a string, it defaults to "same-origin".
- `cache$RqI
- %request の `cache$m を設定する文字列 — 要請は~browserの~cacheとどうヤリトリするかを指示する。 ◎ A string indicating how the request will interact with the browser’s cache to set request’s cache.
- `redirect$RqI
- %request の `redirect$m を設定する — %request は~redirectに際し,次のどれにするかを指示する ⇒# 追従する / ~errorにする / その~redirectを`不透明~redirect絞込み応答$として返す【! *in an opaque fashion】 ◎ A string indicating whether request follows redirects, results in an error upon encountering a redirect, or returns the redirect (in an opaque fashion). Sets request’s redirect.
- `integrity$RqI
- %request の `integrity$m を設定する文字列 — %request により~fetchされる資源の暗号用~hashを与える。 ◎ A cryptographic hash of the resource to be fetched by request. Sets request’s integrity.
- `keepalive$RqI
- %request の `keepalive$m を設定する真偽値。 ◎ A boolean to set request’s keepalive.
- `signal$RqI
- %request の `signal$m を設定する `AbortSignal$I 。 ◎ An AbortSignal to set request’s signal.
- `window$RqI
- ~NULL 以外の値はとり得ない。 %request と `Window$I との結付きを断つために利用される。 ◎ Can only be null. Used to disassociate request from any Window.
- %request . `method$m
- %request の~HTTP~methodを返す。 既定では `GET^l 。 ◎ Returns request’s HTTP method, which is "GET" by default.
- %request . `url$m
- %request の~URLを文字列として返す。 ◎ Returns the URL of request as a string.
- %request . `headers$m
- %request に結付けられている一連の~headerからなる `Headers$I ~objを返す。 この~objには、~UAにより~network層にて追加される~headerは,織り込まれないことに注意 — 例:`Host^l ~headerなど。 ◎ Returns a Headers object consisting of the headers associated with request. Note that headers added in the network layer by the user agent will not be accounted for in this object, e.g., the "Host" header.
- %request . `destination$m
- %request により要請される資源の種類を返す — 例: `document^l / `script^l 。 ◎ Returns the kind of resource requested by request, e.g., "document" or "script".
- %request . `referrer$m
-
%request の~referrerを返す。 その値は:
- %init 内に明示的に設定された場合、同一-生成元~URLになり得る。
- 空~文字列は、~referrerなしを指示する。
- 大域【環境?~obj?】の既定の~referrerになるときは、 `about:client^l になる。
これは、[ ~fetchする間に為される要請の `Referer$h ~header ]の値を決定するときに利用される。
◎ Returns the referrer of request. Its value can be a same-origin URL if explicitly set in init, the empty string to indicate no referrer, and "about:client" when defaulting to the global’s default. This is used during fetching to determine the value of the `Referer` header of the request being made. - %request . `referrerPolicy$m
- %request に結付けられている~referrer施策を返す。 これは、~fetchする間に %request の~referrer値を算出するときに利用される。 ◎ Returns the referrer policy associated with request. This is used during fetching to compute the value of the request’s referrer.
- %request . `mode$m
- %request に結付けられている`~mode$rqを返す。 それは,文字列であり、要請が[ ~CORSを利用する, 同一-生成元~URLに制約される ]のいずれになるかを指示する。 ◎ Returns the mode associated with request, which is a string indicating whether the request will use CORS, or will be restricted to same-origin URLs.
- %request . `credentials$m
- %request に結付けられている`資格証~mode$rqを返す。 それは,文字列であり、送信される要請に,資格証を[ 常に伴わせる, 決して伴わせない, 同一-生成元~URLに限り伴わせる ]のいずれになるかを指示する。 ◎ Returns the credentials mode associated with request, which is a string indicating whether credentials will be sent with the request always, never, or only when sent to a same-origin URL.
- %request . `cache$m
- %request に結付けられている`~cache~mode$rqを返す。 それは,文字列であり、[ 要請を~fetchする際に~browserの~cacheとどうヤリトリするか ]を指示する。 ◎ Returns the cache mode associated with request, which is a string indicating how the request will interact with the browser’s cache when fetching.
- %request . `redirect$m
- %request に結付けられている`~redirect~mode$rqを返す。 それは,文字列であり、[ ~fetchする間,要請に対する~redirectはどう取扱われるか ]を指示する。 既定では、`要請$は~redirectに追従することになる。 ◎ Returns the redirect mode associated with request, which is a string indicating how redirects for the request will be handled during fetching. A request will follow redirects by default.
- %request . `integrity$m
- %request の下位資源~完全性~metadataを返す。 それは、~fetchされる資源の暗号用~hashを与える。 その値は、空白で区切られた 【!multiple】 いくつかの~hashからなる。 `SRI$r ◎ Returns request’s subresource integrity metadata, which is a cryptographic hash of the resource being fetched. Its value consists of multiple hashes separated by whitespace. [SRI]
- %request . `keepalive$m
- %request が[ それを作成した大域~objの外で残存できるかどうか ]を指示する,真偽値を返す。 ◎ Returns a boolean indicating whether or not request can outlive the global in which it was created.
- %request . `isReloadNavigation$m
- %request が[ ~reload~navi用かどうか ]を指示する,真偽値を返す。 ◎ Returns a boolean indicating whether or not request is for a reload navigation.
- %request . `isHistoryNavigation$m
- %request が[ (前後~pageへの)履歴~navi用かどうか ]を指示する,真偽値を返す。 ◎ Returns a boolean indicating whether or not request is for a history navigation (a.k.a. back-foward navigation).
- %request . `signal$m
- %request に結付けられている通達を返す。 それは, `AbortSignal$I ~objであり、[ %request は中止されたかどうか, および その中止-~event~handler ]を指示する。 ◎ Returns the signal associated with request, which is an AbortSignal object indicating whether or not request has been aborted, and its abort event handler.
- %request . `clone()$m
- %request の~cloneを返す。 ◎ Returns a clone of request.
`~Request~objを作成する@ ときは、所与の ( `要請$ %要請, `~Headers用の~guard$ %~guard, ~Realm %~realm ) に対し,次の手続きを走らす: ◎ To create a Request object, given a request request, headers guard guard, and Realm realm, run these steps:
- %~Request~obj ~LET %~realm に属する`新たな$ `Request$I ~obj ◎ Let requestObject be a new Request object with realm.
- %~Request~obj の ⇒# `要請$Rq ~SET %要請, `~Headers$Rq ~SET `~Headers~objを作成する$( %要請 の`~header~list$rq, %~guard, %~realm ), `通達$Rq ~SET %~realm 属する`新たな$ `AbortSignal$I ~obj ◎ Set requestObject’s request to request. ◎ Set requestObject’s headers to a new Headers object with realm, whose headers list is request’s headers list and guard is guard. ◎ Set requestObject’s signal to a new AbortSignal object with realm.
- ~RET %~Request~obj【!request】 ◎ Return request.
`new Request(input, init)@m 構築子~手続きは: ◎ The new Request(input, init) constructor steps are:
- %要請 ~LET ~NULL ◎ Let request be null.
- %~fallback~mode ~LET ~NULL ◎ Let fallbackMode be null.
- %基底~URL ~LET コレに`関連な設定群~obj$の`~API用~基底~URL$enV ◎ Let baseURL be this’s relevant settings object’s API base URL.
- %通達 ~LET ~NULL ◎ Let signal be null.
-
~IF[ %input は文字列である ]: ◎ If input is a string, then:
- %構文解析した~URL ~LET `~URL構文解析する$( %input, %基底~URL ) ◎ Let parsedURL be the result of parsing input with baseURL.
- ~IF[ %構文解析した~URL ~EQ `失敗^i ] ⇒ ~THROW `TypeError$E ◎ If parsedURL is failure, then throw a TypeError.
- ~IF[ %構文解析した~URL は`資格証を含んで$いる ] ⇒ ~THROW `TypeError$E ◎ If parsedURL includes credentials, then throw a TypeError.
- %要請 ~SET 次のようにされた,新たな`要請$ ⇒ `~URL$rq ~SET %構文解析した~URL ◎ Set request to a new request whose URL is parsedURL.
- %~fallback~mode ~SET `cors^l ◎ Set fallbackMode to "cors".
-
~ELSE: ◎ Otherwise:
- ~Assert: %input は `Request$I ~objである。 ◎ Assert: input is a Request object.
- %要請 ~SET %input の`要請$Rq ◎ Set request to input’s request.
- %通達 ~SET %input の`通達$Rq ◎ Set signal to input’s signal.
- %生成元 ~LET コレに`関連な設定群~obj$の`生成元$enV ◎ Let origin be this’s relevant settings object’s origin.
- %~window ~LET `client^l ◎ Let window be "client".
- ~IF[ %要請 の`~window$rqは`環境~設定群~obj$である ]~AND[ ( %要請 の`~window$rqの`生成元$enV, %生成元 ) は`同一-生成元$である ] ⇒ %~window ~SET %要請 の`~window$rq ◎ If request’s window is an environment settings object and its origin is same origin with origin, then set window to request’s window.
-
%init[ "`window$RqI" ] に応じて:
- ε ⇒ 何もしない
- ~NULL ⇒ %~window ~SET `no-window^l
- その他 ⇒ ~THROW `TypeError$E
- %要請 ~SET 次のように設定された,新たな`要請$ ⇒# `~URL$rq ~SET %要請 の`現在の~URL$rq, `~method$rq ~SET %要請 の`~method$rq, `~header~list$rq ~SET %要請 の`~header~list$rqの複製, `非安全~要請~flag$rq ~SET ~T, `~client$rq ~SET コレに`関連な設定群~obj$, `~window$rq ~SET %~window, `優先度$rq ~SET %要請 の`優先度$rq, `生成元$rq ~SET `client^l, `~referrer$rq ~SET %要請 の`~referrer$rq, `~referrer施策$rq ~SET %要請 の`~referrer施策$rq, `~mode$rq ~SET %要請 の`~mode$rq, `資格証~mode$rq ~SET %要請 の`資格証~mode$rq, `~cache~mode$rq ~SET %要請 の`~cache~mode$rq, `~redirect~mode$rq ~SET %要請 の`~redirect~mode$rq, `完全性~metadata$rq ~SET %要請 の`完全性~metadata$rq, `~keepalive$rq ~SET %要請 の`~keepalive$rq, `~reload~navi~flag$rq ~SET %要請 の`~reload~navi~flag$rq, `履歴~navi~flag$rq ~SET %要請 の`履歴~navi~flag$rq ◎ Set request to a new request with the following properties: ◎ URL • request’s current URL. method • request’s method. header list • A copy of request’s header list. unsafe-request flag • Set. client • This’s relevant settings object. window • window. priority • request’s priority. origin • "client". referrer • request’s referrer. referrer policy • request’s referrer policy. mode • request’s mode. credentials mode • request’s credentials mode. cache mode • request’s cache mode. redirect mode • request’s redirect mode. integrity metadata • request’s integrity metadata. keepalive • request’s keepalive. reload-navigation flag • request’s reload-navigation flag. history-navigation flag • request’s history-navigation flag.
-
~IF[ %init は`空$mapでない ]: ◎ If init is not empty, then:
- ~IF[ %要請 の`~mode$rq ~EQ `navigate^l ] ⇒ %要請 の`~mode$rq ~SET `same-origin^l ◎ If request’s mode is "navigate", then set it to "same-origin".
- %要請 の ⇒# `~reload~navi~flag$rq ~SET ~F, `履歴~navi~flag$rq ~SET ~F, `~referrer$rq ~SET `client^l, `~referrer施策$rq ~SET 空~文字列 ◎ Unset request’s reload-navigation flag. ◎ Unset request’s history-navigation flag. ◎ Set request’s referrer to "client" ◎ Set request’s referrer policy to the empty string.
注記: これは、~swが要請 — 例えば,非同一-生成元~stylesheetからの画像 — を “~redirect” して 改変を加えたときに、元の~source(すなわち,非同一-生成元~stylesheet)から来たのでなく,その~swから来たように現れることを確保するために行われる。 元の~sourceは,~swと同じ種類の要請~すら生成できないかもしれないので、このことは重要になる。 これが行われないと、元の~sourceを信用する~serviceは,悪用されかねない — そこまで行き着くことは まず無さそうだが。 ◎ This is done to ensure that when a service worker "redirects" a request, e.g., from an image in a cross-origin style sheet, and makes modifications, it no longer appears to come from the original source (i.e., the cross-origin style sheet), but instead from the service worker that "redirected" the request. This is important as the original source might not even be able to generate the same kind of requests as the service worker. Services that trust the original source could therefore be exploited were this not done, although that is somewhat farfetched.
- %~referrer ~LET %init[ "`referrer$RqI" ] ◎ ↓
-
~IF[ %~referrer ~NEQ ε ]: ◎ If init["referrer"] exists, then: • Let referrer be init["referrer"].
- ~IF[ %~referrer ~EQ 空~文字列 ] ⇒# %要請 の`~referrer$rq ~SET `no-referrer^l ◎ If referrer is the empty string, then set request’s referrer to "no-referrer".
-
~ELSE: ◎ Otherwise:
- %構文解析した~referrer ~LET `~URL構文解析する$( %~referrer, %基底~URL ) ◎ Let parsedReferrer be the result of parsing referrer with baseURL.
- ~IF[ %構文解析した~referrer ~EQ `失敗^i ] ⇒ ~THROW `TypeError$E ◎ If parsedReferrer is failure, then throw a TypeError.
-
~IF[ 次のいずれかが満たされる ]…: ◎ If one of the following is true
-
%構文解析した~referrer は次をいずれも満たす
- `基底~URL不可$url ~EQ ~T
- `~scheme$url ~EQ `about^l
- `~path$url は 単独の文字列 `client^l からなる
- ( %構文解析した~referrer の`生成元$url, %生成元 ) は`同一-生成元$でない ◎ parsedReferrer’s origin is not same origin with origin
…ならば ⇒ %要請 の`~referrer$rq ~SET `client^l ◎ then set request’s referrer to "client".
-
- ~ELSE ⇒ %要請 の`~referrer$rq ~SET %構文解析した~referrer ◎ Otherwise, set request’s referrer to parsedReferrer.
-
~IF[ %init[ "`referrerPolicy$RqI" ] ~NEQ ε ] ⇒ %要請 の`~referrer施策$rq ~SET その値 ◎ If init["referrerPolicy"] exists, then set request’s referrer policy to it.
- %~mode ~LET [ %init[ "`mode$RqI" ] ~NEQ ε ならば その値 / ~ELSE_ %~fallback~mode ] ◎ Let mode be init["mode"] if it exists, and fallbackMode otherwise.
- ~IF[ %~mode ~EQ `navigate^l ] ⇒ ~THROW `TypeError$E ◎ If mode is "navigate", then throw a TypeError.
- ~IF[ %~mode ~NEQ ~NULL ] ⇒ %要請 の`~mode$rq ~SET %~mode ◎ If mode is non-null, set request’s mode to mode.
- ~IF[ %init[ "`credentials$RqI" ] ~NEQ ε ] ⇒ %要請 の`資格証~mode$rq ~SET その値 ◎ If init["credentials"] exists, then set request’s credentials mode to it.
- ~IF[ %init[ "`cache$RqI" ] ~NEQ ε ] ⇒ %要請 の`~cache~mode$rq ~SET その値 ◎ If init["cache"] exists, then set request’s cache mode to it.
- ~IF[ %要請 の`~cache~mode$rq ~EQ `only-if-cached^l ]~AND[ %要請 の`~mode$rq ~NEQ `same-origin^l ] ⇒ ~THROW `TypeError$E ◎ If request’s cache mode is "only-if-cached" and request’s mode is not "same-origin", then throw a TypeError.
- ~IF[ %init[ "`redirect$RqI" ] ~NEQ ε ] ⇒ %要請 の`~redirect~mode$rq ~SET その値 ◎ If init["redirect"] exists, then set request’s redirect mode to it.
- ~IF[ %init[ "`integrity$RqI" ] ~NEQ ε ] ⇒ %要請 の`完全性~metadata$rq ~SET その値 ◎ If init["integrity"] exists, then set request’s integrity metadata to it.
- %要請 の`~keepalive$rq ~SET %init[ "`keepalive$RqI" ] に応じて ⇒# ~T【!init["keepalive"] exists】 ならば ~T / ~ELSE_ ~F ◎ If init["keepalive"] exists, then set request’s keepalive to it.
- %~method ~LET %init[ "`method$RqI" ] ◎ ↓
-
~IF[ %~method ~NEQ ε ]: ◎ If init["method"] exists, then: • Let method be init["method"].
- ~IF[ %~method は`~method$でない ]~OR[ %~method は`禁止~method$である ] ⇒ ~THROW `TypeError$E ◎ If method is not a method or method is a forbidden method, then throw a TypeError.
- %要請 の`~method$rq ~SET `~methodを正規化する$( %~method ) ◎ Normalize method. ◎ Set request’s method to method.
- ~IF[ %init[ "`signal$RqI" ] ~NEQ ε ] ⇒ %通達 ~SET その値 ◎ If init["signal"] exists, then set signal to it.
- コレの`要請$Rq ~SET %要請 ◎ Set this’s request to request.
-
~IF[ %通達 ~NEQ ~NULL ] ⇒ `通達に追従させる$( コレの`通達$Rq, %通達 ) ◎ If signal is not null, then make this’s signal follow signal.
- コレの`~Headers$Rq ~SET `~Headers~objを作成する$( %要請 の`~header~list$rq, `request^l, コレに`関連な~Realm$ ) ◎ Set this’s headers to a new Headers object with this’s relevant Realm, whose header list is request’s header list and guard is "request".
-
~IF[ コレの`要請$Rqの`~mode$rq ~EQ `no-cors^l ]: ◎ If this’s request’s mode is "no-cors", then:
- ~IF[ コレの`要請$Rqの`~method$rqは `~CORS安全とされる~method$でない ] ⇒ ~THROW `TypeError$E ◎ If this’s request’s method is not a CORS-safelisted method, then throw a TypeError.
- コレの`~Headers$Rqの`~guard$Hl ~SET `request-no-cors^l ◎ Set this’s headers’s guard to "request-no-cors".
-
~IF[ %init は`空$mapでない ]: ◎ If init is not empty, then:
注記: %headers は,この~mode【 %~mode? 】では許容されない~headerを包含するかもしれないので、この段で無毒化される。 他の場合、それは以前に無毒化されたか,特権的~APIによる設定-時から改変されてない。 ◎ The headers are sanitized as they might contain headers that are not allowed by this mode. Otherwise, they were previously sanitized or are unmodified since they were set by a privileged API.
- %headers ~LET %init[ "`headers$RqI" ] ◎ ↓
- ~IF[ %headers ~EQ ε ] ⇒ %headers ~SET コレの`~Headers$Rqの複製 — `~header~list$Hlも含めて複製する ◎ Let headers be a copy of this’s headers and its associated header list. ◎ If init["headers"] exists, then set headers to init["headers"].
- コレの`~Headers$Rqの`~header~list$Hlを空にする ◎ Empty this’s headers’s header list.
- ~IF[ %headers は `Headers$I ~objである ] ⇒ %headers の`~header~list$Hl内の ~EACH( %~header ) に対し ⇒ コレの`~Headers$Rqに ( %~header の`名前$hd / %~header の`値$hd ) を`付加する$Hl ◎ If headers is a Headers object, then for each header in its header list, append header’s name/header’s value to this’s headers.
- ~ELSE ⇒ コレの`~Headers$Rqを %headers で`埋める$Hl ◎ Otherwise, fill this’s headers with headers.
- %入力~本体 ~LET %input に応じて ⇒# `Request$I ~objであるならば %input の`要請$Rqの`本体$rq / ~ELSE_ ~NULL ◎ Let inputBody be input’s request’s body if input is a Request object; otherwise null.
- %本体~member ~LET [ %init[ "`body$RqI" ] ~NEQ ε ならば その値 / ~ELSE_ ~NULL ] ◎ ↓
- ~IF[[ %本体~member ~NEQ ~NULL ]~OR[ %入力~本体 ~NEQ ~NULL ]]~AND[ %要請 の`~method$rq ~IN { `GET$hm, `HEAD$hm } ] ⇒ ~THROW `TypeError$E ◎ If either init["body"] exists and is non-null or inputBody is non-null, and request’s method is `GET` or `HEAD`, then throw a TypeError.
- %初期~本体 ~LET ~NULL ◎ Let initBody be null.
-
~IF[ %本体~member ~NEQ ~NULL ]: ◎ If init["body"] exists and is non-null, then:
- %内容~型 ~LET ~NULL ◎ Let Content-Type be null.
- ( %初期~本体, %内容~型 ) ~SET %要請 の`~keepalive$rq に応じて ⇒# ~T ならば `本体と内容~型を抽出する$( %本体~member, `~keepalive$i ) / ~F ならば `本体と内容~型を抽出する$( %本体~member ) ◎ Set initBody and Content-Type to the result of extracting init["body"], with keepalive set to request’s keepalive.
- ~IF[ %内容~型 ~NEQ ~NULL ]~AND[[ コレの`~Headers$Rqの`~header~list$Hl ]内に[ `Content-Type$h を`名前に持つ~header$ ]は無い ] ⇒ コレの`~Headers$Rqに ( `Content-Type$h / %内容~型 ) を`付加する$Hl ◎ If Content-Type is non-null and this’s headers’s header list does not contain `Content-Type`, then append `Content-Type`/Content-Type to this’s headers.
- %最終-本体【!inputOrInitBody(不要)】 ~LET [ %初期~本体 ~NEQ ~NULL ならば %初期~本体 / ~ELSE_ %入力~本体 ] ◎ Let inputOrInitBody be initBody if it is non-null; otherwise inputBody.
-
~IF[ %最終-本体 ~NEQ ~NULL ]~AND[ %最終-本体 の`~source$bd ~EQ ~NULL ]: ◎ If inputOrInitBody is non-null and inputOrInitBody’s source is null, then:
- ~IF[ コレの`要請$Rqの`~mode$rq ~NIN { `same-origin^l, `cors^l } ] ⇒ ~THROW `TypeError$E ◎ If this’s request’s mode is neither "same-origin" nor "cors", then throw a TypeError.
- コレの`要請$Rqの`~CORS予行~利用~flag$rq ~SET ~T ◎ Set this’s request’s use-CORS-preflight flag.
-
~IF[ %初期~本体 ~EQ ~NULL ]~AND[ %入力~本体 ~NEQ ~NULL ]: ◎ ↑Let finalBody be inputOrInitBody. ◎ If initBody is null and inputBody is non-null, then:
- ~IF[ %input は`利用-不能$Bdである ] ⇒ ~THROW `TypeError$E ◎ If input is unusable, then throw a TypeError.
- %最終-本体 ~SET `~proxyを作成する$RS( %入力~本体 ) ◎ Set finalBody to the result of creating a proxy for inputBody.
- コレの`要請$Rqの`本体$rq ~SET %最終-本体 ◎ Set this’s request’s body to finalBody.
- コレの`通達$Rq ~SET コレに`関連な~Realm$に属する`新たな$ `AbortSignal$I ~obj ◎ Set this’s signal to a new AbortSignal object with this’s relevant Realm.
`clone()@m ~method~手続きは: ◎ The clone() method steps are:
- ~IF[ コレは`利用-不能$Bdである ] ⇒ ~THROW `TypeError$E ◎ If this is unusable, then throw a TypeError.
- %~cloneした要請 ~LET `要請を~cloneする$( コレの`要請$Rq ) ◎ Let clonedRequest be the result of cloning this’s request.
- %~cloneした~Request~obj ~LET `~Request~objを作成する$( %~cloneした要請, コレの`~Headers$Rqの`~guard$Hl, コレに`関連な~Realm$ ) ◎ Let clonedRequestObject be the result of creating a Request object, given clonedRequest, this’s headers’s guard, and this’s relevant Realm.
- `通達に追従させる$( %~cloneした~Request~obj の`通達$Rq, コレの`通達$Rq ) ◎ Make clonedRequestObject’s signal follow this’s signal.
- ~RET %~cloneした~Request~obj ◎ Return clonedRequestObject.
5.5. `Response^I ~class
[`Exposed$=(Window,Worker)] interface `Response@I { `Response$mc(optional `BodyInit$I? %body = null, optional `ResponseInit$I %init = {}); [`NewObject$] static `Response$I `error$m(); [`NewObject$] static `Response$I `redirect$m( `USVString$ %url, optional `unsigned short$ %status = 302 ); readonly attribute `ResponseType$I `type$m; readonly attribute `USVString$ `url$m; readonly attribute `boolean$ `redirected$m; readonly attribute `unsigned short$ `status$m; readonly attribute `boolean$ `ok$m; readonly attribute `ByteString$ `statusText$m; [`SameObject$] readonly attribute `Headers$I `headers$m; [`NewObject$] `Response$I `clone$m(); }; `Response$I includes `Body$I; dictionary `ResponseInit@I { `unsigned short$ `status@RsI = 200; `ByteString$ `statusText@RsI = ""; `HeadersInit$I `headers@RsI; }; enum `ResponseType@I { "basic", "cors", "default", "error", "opaque", "opaqueredirect" };
各 `Response$I ~objには、次に挙げるものが結付けられる: ◎ ↓
- `応答@Rs
- `応答$。 ◎ A Response object has an associated response (a response).
- `~Headers@Rs
- ~NULL または `Headers$I ~obj — 初期~時は ~NULL 。 ◎ A Response object also has an associated headers (null or a Headers object), initially null.
`Response$I ~objの`~MIME型$Bdは、次の結果を返す ⇒ `~header~listから~MIME型を抽出する$( ~objの`応答$Rsの`~header~list$rs ) ◎ A Response object’s MIME type is to return the result of extracting a MIME type from its response’s header list.
`Response$I ~objの`本体$Bdは、その`応答$Rsの`本体$rsである。 ◎ A Response object’s body is its response’s body.
- %response = `new Response(body = null [, init])$m
- `Response$I を作成して,その本体を %body にする — [ 状態s, 状態s~message, ~header~list ]は、 %init により供される。 ◎ Creates a Response whose body is body, and status, status message, and headers are provided by init.
- %response = `Response$I . `error()$m
- ~network~errorを表現する `Response$I を作成する。 ◎ Creates network error Response.
- %response = `Response$I . `redirect(url, status = 302)$m
- ~redirectを表現する `Response$I を作成する — 状態sに %status を伴い, %url へ~redirectするような。 ◎ Creates a redirect Response that redirects to url with status status.
- %response . `type$m
- %response の種別を返す — 例: `cors^l 。 ◎ Returns response’s type, e.g., "cors".
- %response . `url$m
- %response に~URLが[ 在るならば それ/ 無いならば空~文字列 ]を返す。 ◎ Returns response’s URL, if it has one; otherwise the empty string.
- %response . `redirected$m
- %response は、~redirectを通して得されたかどうかを返す。 ◎ Returns whether response was obtained through a redirect.
- %response . `status$m
- %response の状態sを返す。 ◎ Returns response’s status.
- %response . `ok$m
- %response の状態sは`~ok状態s$であるかどうかを返す。 ◎ Returns whether response’s status is an ok status.
- %response . `statusText$m
- %response の状態s~messageを返す。 ◎ Returns response’s status message.
- %response . `headers$m
- %response の~header~listを `Headers$I として返す。 ◎ Returns response’s headers as Headers.
- %response . `clone()$m
- %response の~cloneを返す。 ◎ Returns a clone of response.
`~Response~objを作成する@ ときは、所与の ( `応答$ %応答, `~Headers用の~guard$ %~guard, ~Realm %~realm ) に対し,次の手続きを走らす: ◎ To create a Response object, given a response response, headers guard guard, and Realm realm, run these steps:
- %~Response~obj ~LET %~realm に属する`新たな$ `Response$I ~obj ◎ Let responseObject be a new Response object with realm.
- %~Response~obj の ⇒# `応答$Rs ~SET %応答, `~Headers$Rs ~SET `~Headers~objを作成する$( %応答 の`~header~list$rs, %~guard, %~realm ) ◎ Set responseObject’s response to response. ◎ Set responseObject’s headers to a new Headers object with realm, whose headers list is response’s headers list and guard is guard.
- ~RET %~Response~obj ◎ Return responseObject.
`new Response(body, init)@m 構築子~手続きは: ◎ The new Response(body, init) constructor steps are:
- ~IF[ %init[ "`status$RsI" ] ~NIN { `200^st 〜 `599^st } ] ⇒ ~THROW `RangeError$E ◎ If init["status"] is not in the range 200 to 599, inclusive, then throw a RangeError.
- ~IF[ %init[ "`statusText$RsI" ] は `reason-phrase$p ~token生成規則に合致しない ] ⇒ ~THROW `TypeError$E ◎ If init["statusText"] does not match the reason-phrase token production, then throw a TypeError.
- %応答 ~LET 新たな`応答$ ◎ ↓
- コレの`応答$Rs ~SET %応答 ◎ Set this’s response to a new response.
- コレの`~Headers$Rs ~SET `~Headers~objを作成する$( %応答 の`~header~list$rs, `response^l, コレに`関連な~Realm$ ) ◎ Set this’s headers to a new Headers object with this’s relevant Realm, whose header list is this’s response’s header list and guard is "response".
- %応答 の`状態s$rs ~SET %init[ "`status$RsI" ] ◎ Set this’s response’s status to init["status"].
- %応答 の`状態s~message$rs ~SET %init[ "`statusText$RsI" ] ◎ Set this’s response’s status message to init["statusText"].
- ~IF[ %init[ "`headers$RsI" ] ~NEQ ε ] ⇒ コレの`~Headers$Rsを %init[ "`headers$RsI" ] で`埋める$Hl ◎ If init["headers"] exists, then fill this’s headers with init["headers"].
-
~IF[ %body ~NEQ ~NULL ]: ◎ If body is non-null, then:
-
~IF[ %init[ "`status$RsI" ] は`~null本体~状態s$である ] ⇒ ~THROW `TypeError$E ◎ If init["status"] is a null body status, then throw a TypeError.
注記: `101$st は、この段には影響しない — それは、他所におけるその利用に因り,`~null本体~状態s$に含まれているので。 ◎ 101 is included in null body status due to its use elsewhere. It does not affect this step.
- %内容~型 ~LET ~NULL ◎ Let Content-Type be null.
- ( %応答 の`本体$rs, %内容~型 ) ~SET `本体と内容~型を抽出する$( %body ) ◎ Set this’s response’s body and Content-Type to the result of extracting body.
- ~IF[ %内容~型 ~NEQ ~NULL ]~AND[ %応答 の`~header~list$rs内に[ `Content-Type$h を`名前に持つ~header$ ]は無い ] ⇒ %応答 の`~header~list$rsに`~headerを付加する$( `Content-Type$h / %内容~型 ) ◎ If Content-Type is non-null and this’s response’s header list does not contain `Content-Type`, then append `Content-Type`/Content-Type to this’s response’s header list.
-
`redirect(url, status)@m 静的~method~手続きは: ◎ The static redirect(url, status) method steps are:
- %構文解析した~URL ~LET `~URL構文解析する$( %url, `現在の設定群~obj$の`~API用~基底~URL$enV ) ◎ Let parsedURL be the result of parsing url with current settings object’s API base URL.
- ~IF[ %構文解析した~URL ~EQ `失敗^i ] ⇒ ~THROW `TypeError$E ◎ If parsedURL is failure, then throw a TypeError.
- ~IF[ %status は `~redirect状態s$でない ] ⇒ ~THROW `RangeError$E ◎ If status is not a redirect status, then throw a RangeError.
- %~Response~obj ~LET `~Response~objを作成する$( 新たな`応答$, `immutable^l, コレに`関連な~Realm$ ) ◎ Let responseObject be the result of creating a Response object, given a new response, "immutable", and this’s relevant Realm.
- %~Response~obj の`応答$Rsの`状態s$rs ~SET %status ◎ Set responseObject’s response’s status to status.
- %値 ~LET `同型に符号化する$( `~URLを直列化する$( %構文解析した~URL ) ) ◎ Let value be parsedURL, serialized and isomorphic encoded.
- %~Response~obj の`応答$Rsの`~header~list$rsに`~headerを付加する$( `Location$h / %値 ) ◎ Append `Location`/value to responseObject’s response’s header list.
- ~RET %~Response~obj ◎ Return responseObject.
`redirected@m 取得子~手続きは ⇒ ~RET [ 次が満たされるならば ~T / ~ELSE_ ~F ] ⇒ コレの`応答$Rsの`~URL~list$rsの`~size$ ~GT 1 ◎ The redirected getter steps are to return true if this’s response’s URL list has more than one item; otherwise false.
注記: ~redirectの結果による`応答$をはじくときは、~APIを通して直に行う — 例えば `fetch(url, { redirect:"error" })^c のように。 こうすれば、安全でないものにもなり得る`応答$が不用意に漏洩されるのを~~防げる。 ◎ To filter out responses that are the result of a redirect, do this directly through the API, e.g., fetch(url, { redirect:"error" }). This way a potentially unsafe response cannot accidentally leak.
`clone()@m ~method~手続きは: ◎ The clone() method steps are:
- ~IF[ コレは`利用-不能$Bdである ] ⇒ ~THROW `TypeError$E ◎ If this is unusable, then throw a TypeError.
- %~cloneした応答 ~LET `応答を~cloneする$( コレの`応答$Rs ) ◎ Let clonedResponse be the result of cloning this’s response.
- ~RET `~Response~objを作成する$( %~cloneした応答, コレの`~Headers$Rsの`~guard$Hl, コレに`関連な~Realm$ ) ◎ Return the result of creating a Response object, given clonedResponse, this’s headers’s guard, and this’s relevant Realm.
5.6. `fetch^m ~method
partial interface mixin `WindowOrWorkerGlobalScope$I { [`NewObject$] `Promise$<`Response$I> `fetch$m( `RequestInfo$I %input, optional `RequestInit$I %init = {} ); };
`fetch(input, init)@m ~method~手続きは: ◎ The fetch(input, init) method steps are:
- %~promise ~LET `新たな~promise$ ◎ Let p be a new promise.
- %~Request~obj ~LET 新たな `Request$I ~obj ◎ ↓
- %~Request~obj 上の `new Request$m 構築子~手続き( %input, %init ) 【!構築子の初期~値を呼出した結果】 ⇒ 例外が投出された場合は ⇒# その例外で %~promise を`却下する$; ~RET %~promise ◎ Let requestObject be the result of invoking the initial value of Request as constructor with input and init as arguments. If this throws an exception, reject p with it and return p.
- %要請 ~LET %~Request~obj の`要請$Rq ◎ Let request be requestObject’s request.
-
~IF[ %~Request~obj の`通達$Rqの`中止-済み~flag$aB ~EQ ~T ]: ◎ If requestObject’s signal’s aborted flag is set, then:
- `~fetchを中止する$( %~promise, %要請, ~NULL ) ◎ Abort fetch with p, request, and null.
- ~RET %~promise ◎ Return p.
- ~IF[ %要請 の`~client$rqの`大域~obj$enVは `ServiceWorkerGlobalScope$I ~objである ] ⇒ %要請 の`~sw~mode$rq ~SET `none^l ◎ If request’s client’s global object is a ServiceWorkerGlobalScope object, then set request’s service-workers mode to "none".
- %~Response~obj ~LET ~NULL ◎ Let responseObject be null.
- %関連な~Realm ~LET コレに`関連な~Realm$ ◎ Let relevantRealm be this’s relevant Realm.
-
%局所的に中止された ~LET ~F ◎ Let locallyAborted be false.
注記: これは、~fetchの~callと同じ~threadから中止するよう要請されたとき,~promiseを却下する時機を予測-可能にするためにある。 ◎ This lets us reject promises with predictable timing, when the request to abort comes from the same thread as the call to fetch.
-
`通達に~algoを追加する$( %~Request~obj の`通達$Rq, 次を走らす手続き ): ◎ Add the following abort steps to requestObject’s signal:
- %局所的に中止された ~SET ~T ◎ Set locallyAborted to true.
- `~fetchを中止する$( %~promise, %要請, %~Response~obj ) ◎ Abort fetch with p, request, and responseObject.
- 進行中の~fetchを`終了させる$( `中止する^i ) ◎ Terminate the ongoing fetch with the aborted flag set.
-
%要請 を`~fetchする$ — 次を与える下で: ◎ Fetch request with\
-
`応答を処理する$i ~SET 所与の ( %応答 ) に対し,次を走らす下位手続き: ◎ processResponse given response being these substeps:
- ~IF[ %局所的に中止された ~EQ ~T ] ⇒ ~RET ◎ If locallyAborted is true, terminate these substeps.
- ~IF[ %応答 の`中止~flag$rs ~EQ ~T ] ⇒# `~fetchを中止する$( %~promise, %要請, %~Response~obj ); ~RET ◎ If response’s aborted flag is set, then abort fetch with p, request, and responseObject, and terminate these substeps.
- ~IF[ %応答 は`~network~error$である ] ⇒# `TypeError$E で %~promise を`却下する$; ~RET ◎ If response is a network error, then reject p with a TypeError and terminate these substeps.
- %~Response~obj ~SET `~Response~objを作成する$( %応答, `immutable^l, %関連な~Realm ) ◎ Set responseObject to the result of creating a Response object, given response, "immutable", and relevantRealm.
- %~Response~obj で %~promise を`解決する$ ◎ Resolve p with responseObject.
-
- ~RET %~promise ◎ Return p.
`~fetchを中止する@ ときは、所与の ( %~promise, %要請, %~Response~obj ) に対し、次を走らす: ◎ To abort fetch with a promise, request, and responseObject, run these steps:
- %~error ~LET `AbortError$E 例外 ◎ Let error be an "AbortError" DOMException.
-
%~error で %~promise を`却下する$ ◎ Reject promise with error.
注記: %~promise がすでに充足されていた場合、これは何もしない。 ◎ This is a no-op if promise has already fulfilled.
- ~IF[ %要請 の`本体$rq ~NEQ ~NULL ]~AND[ %要請 の`本体$rqは`読取n可能$RSである ] ⇒ %要請 の`本体$rqを`取消す$RS( %~error ) ◎ If request’s body is not null and is readable, then cancel request’s body with error.
- ~IF[ %~Response~obj ~EQ ~NULL ] ⇒ ~RET ◎ If responseObject is null, then return.
- %応答 ~LET %~Response~obj の`応答$Rs ◎ Let response be responseObject’s response.
- ~IF[ %応答 の`本体$rs ~NEQ ~NULL ]~AND[ %応答 の`本体$rsは`読取n可能$RSである ] ⇒ %応答 の`本体$rsを`~errorにする$RS( %~error ) ◎ If response’s body is not null and is readable, then error response’s body with error.
5.7. ~garbage収集
~UAは、進行中の~fetchを — その終了が~scriptを通して観測-可能にならないならば — `終了させ$てもヨイ。 ◎ The user agent may terminate an ongoing fetch if that termination is not observable through script.
注記: “~scriptを通して観測-可能にならない” とは、[ `fetch()$m の引数や返り値を通して観測-可能にはならない ]ことを意味する。 ~serverとの別の通信-法を通して可能になるものなど,他の仕方は含まれない。 ◎ "Observable through script" means observable through fetch()’s arguments and return value. Other ways, such as communicating with the server through a side-channel are not included.
注記: ~serverは、~garbage収集が~~起きたことを観測できる — 例えば[ `WebSocket$I / `XMLHttpRequest$I ]~objを通してなど。 ◎ The server being able to observe garbage collection has precedent, e.g., with WebSocket and XMLHttpRequest objects.
終了は観測され得ないので、~UAは,~fetchを終了させれる: ◎ The user agent can terminate the fetch because the termination cannot be observed.
fetch(`https://www.example.com/^l)
終了は,~promiseを通して観測され得るので、~UAは~fetchを終了させれない: ◎ The user agent cannot terminate the fetch because the termination can be observed through the promise.
window.promise = fetch(`https://www.example.com/^l)
結付けられている本体は観測-可能にならないので、~UAは~fetchを終了させれる: ◎ The user agent can terminate the fetch because the associated body is not observable.
window.promise = fetch(`https://www.example.com/^l) .then( %res => %res.headers )
終了は観測され得ないので、~UAは~fetchを終了させれる: ◎ The user agent can terminate the fetch because the termination cannot be observed.
fetch(`https://www.example.com/^l) .then( %res => %res.body.getReader().closed )
~promise~obj用に~handlerを登録すれば,終了を観測できるので、~UAは~fetchを終了させれない: ◎ The user agent cannot terminate the fetch because one can observe the termination by registering a handler for the promise object.
window.promise = fetch(`https://www.example.com/^l) .then( %res => %res.body.getReader().closed )
登録された~handlerを介して終了が観測-可能になるので、~UAは~fetchを終了させれない: ◎ The user agent cannot terminate the fetch as termination would be observable via the registered handler.
fetch(`https://www.example.com/^l) .then( %res => { %res.body.getReader().closed .then(() => console.log(`~streamは~closeされた!^l)) })【!stream closed!】
(上の例が観測-可能にならないことは、組込みの[ ~prop, 関数 ] — `body.getReader()$c など — が上書きされていないことを前提にしている。) ◎ (The above examples of non-observability assume that built-in properties and functions, such as body.getReader(), have not been overwritten.)
6. ~WebSocket~protocolの改め
注記: この節は、~WebSocket~protocolの~opening~handshakeに課される~client要件の一部を,~Fetchにて定義される~algoに統合するために置換する。 ~CSP, ~cookie, HSTS, その他, Fetch に関係する~protocolは、この仕方で,一箇所に集約して取扱われるようになる。 ~RFCがこの文言で更新されるのが理想だが、それは決して容易にはならない。 ~HTML標準に定義される~WebSocket~APIは、この文言を利用するように更新された。 `WSP$r `HTML$r ◎ This section replaces part of the WebSocket protocol opening handshake client requirement to integrate it with algorithms defined in Fetch. This way CSP, cookies, HSTS, and other Fetch-related protocols are handled in a single location. Ideally the RFC would be updated with this language, but it is never that easy. The WebSocket API, defined in the HTML Standard, has been updated to use this language. [WSP] [HTML]
これは、 `WebSocket Protocol^cite の “~WebSocket接続を確立する” ~algoを,新たなものに置換して~Fetchに統合するような仕方で働く — “~WebSocket接続を確立する” は、 3 つの~algo[ 接続を設定しておく, ~handshake要請を作成して伝送する, ~handshake応答を検証する ]からなる。 その重ね方は、~Fetchによる[ 先ず~handshakeを作成し, 次に接続を設定しておいてから、~handshakeを伝送し, ~~最後に応答を検証する ]のとは,異なる。 この改めを読むときは、そのことを念頭に置くこと。 ◎ The way this works is by replacing The WebSocket Protocol’s "establish a WebSocket connection" algorithm with a new one that integrates with Fetch. "Establish a WebSocket connection" consists of three algorithms: setting up a connection, creating and transmiting a handshake request, and validating the handshake response. That layering is different from Fetch, which first creates a handshake, then sets up a connection and transmits the handshake, and finally validates the response. Keep that in mind while reading these alterations.
6.1. 接続
`~WebSocket接続を得する@ ときは、所与の ( %~url ) に対し,次の手続きを走らす: ◎ To obtain a WebSocket connection, given a url, run these steps:
- %host ~LET %~url の`~host$url ◎ Let host be url’s host.
- %port ~LET %~url の`~port$url ◎ Let port be url’s port.
- %secure ~LET [ %~url の`~scheme$url ~EQ `http^l ならば ~F / ~ELSE_ ~T ] ◎ Let secure be false, if url’s scheme is "http", and true otherwise.
- ( %host, %port, %secure ) を与える下で, `WebSocket Protocol^cite § 4.1 の 前半の手続き の段 2 〜 5 に言明されている要件に従って,~WebSocket接続を確立する `WSP$r ◎ Follow the requirements stated in step 2 to 5, inclusive, of the first set of steps in section 4.1 of The WebSocket Protocol to establish a WebSocket connection. [WSP]
- ~RET[ 接続は確立されたなら それ / ~ELSE_ `失敗^i ] ◎ If that established a connection, return it, and return failure otherwise.
注記: ~WebSocket接続は、異なる~propを運ぶ少し異なる~~構成なので,共有できないが、 “普通の” `接続$にごく近いものである。 ◎ Although structured a little differently, carrying different properties, and therefore not shareable, a WebSocket connection is very close to identical to an "ordinary" connection.
6.2. ~opening~handshake
`~WebSocket~protocol~handshakeを確立する@ ときは、所与の ( %~url, %~protocol~list, %~client ) に対し,次の手続きを走らす: ◎ To establish a WebSocket connection, given a url, protocols, and client, run these steps:
- %要請~URL ~LET %~url の複製 ◎ ↓
-
%要請~URL の`~scheme$url ~SET [ %~url の`~scheme$url ~EQ `ws^l ならば `http^l / ~ELSE_ `https^l ] ◎ Let requestURL be a copy of url, with its scheme set to "http", if url’s scheme is "ws", and to "https" otherwise.
注記: この~schemeの変更-は、`~fetching$に上手く統合するために本質的になる。 例えば HSTS は、こうしないと働かなくなる。 これは、旧来の遺物である — ~WebSocketを別個の~schemeにする~~本当の理由はない。 `HSTS$r ◎ This change of scheme is essential to integrate well with fetching. E.g., HSTS would not work without it. There is no real reason for WebSocket to have distinct schemes, it’s a legacy artefact. [HSTS]
- %要請 ~LET 次のようにされた新たな`要請$ ⇒# `~URL$rq ~SET %要請~URL, `~client$rq ~SET %~client, `~sw~mode$rq ~SET `none^l, `~referrer$rq ~SET `no-referrer^l, `~mode$rq ~SET `websocket^l, `資格証~mode$rq ~SET `include^l, `~cache~mode$rq ~SET `no-store^l, `~redirect~mode$rq ~SET `error^l ◎ Let request be a new request, whose URL is requestURL, client is client, service-workers mode is "none", referrer is "no-referrer", mode is "websocket", credentials mode is "include", cache mode is "no-store", and redirect mode is "error".
- %要請 の`~header~list$rqに`~headerを付加する$( `Upgrade$h / `websocket^bl ) ◎ Append `Upgrade`/`websocket` to request’s header list.
- %要請 の`~header~list$rqに`~headerを付加する$( `Connection$h / `Upgrade^bl ) ◎ Append `Connection`/`Upgrade` to request’s header list.
-
%~key値 ~LET `同型に符号化する$( `~forgiving-base64符号化する$( ~randomに選定された 16 ~byteの値 ) ) ◎ Let keyValue be a nonce consisting of a randomly selected 16-byte value that has been forgiving-base64-encoded and isomorphic encoded.
例えば,~randomに選定された値が~byte列[ `01^X `02^X `03^X `04^X `05^X `06^X `07^X `08^X `09^X `0a^X `0b^X `0c^X `0d^X `0e^X `0f^X `10^X ]ならば、 %~key値 は,それを~forgiving-base64符号化した結果 `AQIDBAUGBwgJCgsMDQ4PEC==^l を同型に符号化した結果 `AQIDBAUGBwgJCgsMDQ4PEC==^bl になる。 ◎ If the randomly selected value was the byte sequence 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, keyValue would be forgiving-base64-encoded to "AQIDBAUGBwgJCgsMDQ4PEC==" and isomorphic encoded to `AQIDBAUGBwgJCgsMDQ4PEC==`.
- %要請 の`~header~list$rqに`~headerを付加する$( `Sec-WebSocket-Key^h / %~key値 ) ◎ Append `Sec-WebSocket-Key`/keyValue to request’s header list.
- %要請 の`~header~list$rqに`~headerを付加する$( `Sec-WebSocket-Version^h / `13^bl ) ◎ Append `Sec-WebSocket-Version`/`13` to request’s header list.
- %~protocol~list 内の ~EACH( %~protocol ) に対し ⇒ %要請 の`~header~list$rq内で`~headerを結合する$( `Sec-WebSocket-Protocol^h / %~protocol ) ◎ For each protocol in protocols, combine `Sec-WebSocket-Protocol`/protocol in request’s header list.
-
%permessageDeflate ~LET ~UAにより定義される `permessage-deflate^l 拡張 `~header$`値$hd `WSP$r 【! [WSP-Compression] 】 ◎ Let permessageDeflate be a user-agent defined "permessage-deflate" extension header value. [WSP]
`permessage-deflate; client_max_window_bits^bl - %要請 の`~header~list$rqに`~headerを付加する$( `Sec-WebSocket-Extensions^h / %permessageDeflate ) ◎ Append `Sec-WebSocket-Extensions`/permessageDeflate to request’s header list.
-
%要請 を`~fetchする$ — 次を与える下で:
- `並列~queueを利用する?$i ~SET ~T
-
`応答を処理する$i ~SET 所与の ( %応答 ) に対し,次を走らす手続き: ◎ Fetch request with useParallelQueue set to true, and processResponse given response being these steps:
- ~IF[ %応答 は`~network~error$である ]~OR[ %応答 の`状態s$rs ~NEQ `101$st ] ⇒ `~WebSocket接続を失敗させる$ ◎ If response is a network error or its status is not 101, fail the WebSocket connection.
-
~IF[ %~protocol~list は空でない ]~AND[ `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Sec-WebSocket-Protocol^h ) ~IN { ~NULL, `失敗^i, 空~byte列 } ] ⇒ `~WebSocket接続を失敗させる$ ◎ If protocols is not the empty list and extracting header list values given `Sec-WebSocket-Protocol` and response’s header list results in null, failure, or the empty byte sequence, then fail the WebSocket connection.
注記: これは、 `WebSocket Protocol^cite にて定義される,この~headerに対する検査と異なる。 そこでは、~clientから要請されていない下位protocolがある場合しか受持ってなかった。 ここでは、~clientから要請された下位protocolが~serverから承認されていない場合も受持つ。 ◎ This is different from the check on this header defined by The WebSocket Protocol. That only covers a subprotocol not requested by the client. This covers a subprotocol requested by the client, but not acknowledged by the server.
- `WebSocket Protocol^cite § 4.1 の後半の手続きの段 2 〜 6 に言明されている要件に従って, %応答 を検証する — これは、`~WebSocket接続を失敗させる$か, `~WebSocket接続は確立される$ことになる。 ◎ Follow the requirements stated step 2 to step 6, inclusive, of the last set of steps in section 4.1 of The WebSocket Protocol to validate response. This either results in fail the WebSocket connection or the WebSocket connection is established.
`~WebSocket接続を失敗させる@ 【参照先】 / `~WebSocket接続は確立される@ 【参照先】 は、 `WebSocket Protocol^cite にて定義される。 `WSP$r ◎ Fail the WebSocket connection and the WebSocket connection is established are defined by The WebSocket Protocol. [WSP]
警告: ~redirectを追わない理由は、~web~browser文脈に深刻な~security問題をもたらすからである。 そのため、この~handshakeは,一般に制約される。 例えば、ある~hostが ある~pathに~WebSocket~serverを立てていたとする。 その~hostが,別の~pathにも ~openな~HTTP~redirect器 【`参考^】 を立てた時点で、~WebSocket~URLを与え得るような どの~scriptも,その~URLの~hostnameが~~正しいことを検査したとしても,~internet上の~~任意の~hostと通信する(したがって秘匿情報を共有し得る)ように騙すことが可能になる。 【! https://www.ietf.org/mail-archive/web/hybi/current/msg06951.html】 ◎ The reason redirects are not followed and this handshake is generally restricted is because it could introduce serious security problems in a web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the internet, even if the script checks that the URL has the right hostname.
7. ~data_URL
~data_URLについての規範的でない記述は、 `RFC2397$r を見よ。 この節は、その~RFCの規範的な処理~要件を,配備-済み内容と互換になるよう置換する。 ◎ For an informative description of data: URLs, see RFC 2397. This section replaces that RFC’s normative processing requirements to be compatible with deployed content. [RFC2397]
`~data_URL構造体@ は、次に挙げるものからなる`構造体$である:
- `~MIME型@dU
- `~MIME型$。
- `本体@dU
- `~byte列$。
`~data_URL処理器@ は、所与の ( `~URL$ %~dataURL ) に対し,次の手続きを走らす: ◎ The data: URL processor takes a URL dataURL and then runs these steps:
- ~Assert: %~dataURL の`~scheme$url ~EQ `data^l ◎ Assert: dataURL’s scheme is "data".
- %入力 ~LET `~URLを直列化する$( %~dataURL, `素片は除外する$i ) ◎ Let input be the result of running the URL serializer on dataURL with exclude fragment set to true.
- %入力 から頭部を成す文字列 `data:^l を除去する ◎ Remove the leading "data:" string from input.
- %位置 ~LET %入力 の先頭を指している`位置~変数$ ◎ Let position point at the start of input.
- %~MIME型 ~LET %入力 内の %位置 から `002C^U `,^smb 以外の`符号位置~並びを収集する$ ◎ Let mimeType be the result of collecting a sequence of code points that are not equal to U+002C (,), given position.
-
%~MIME型 ~LET `前後の~ASCII空白~列を剥ぐ$( %~MIME型 ) ◎ Strip leading and trailing ASCII whitespace from mimeType.
注記: これが除去する`符号位置$は、 `0020^U `SPACE^cn に限られる。 ◎ This will only remove U+0020 SPACE code points, if any.
- ~IF[ %位置↗ ~EQ ε ] ⇒ ~RET `失敗^i ◎ If position is past the end of input, then return failure.
- %位置 ~INCBY 1 ◎ Advance position by 1.
- %復号-済み本体 ~LET %入力 内の %位置 からすべての`符号位置~並びを収集する$ ◎ Let encodedBody be the remainder of input.
- %本体 ~LET `文字列を~byte列に~percent-復号する$( %復号-済み本体 ) ◎ Let body be the percent-decoding of encodedBody.
-
~IF[ %~MIME型 は次の順の並びに合致する ]… ⇒# 任意の文字列 %S, `003B^U `;^smb, 0 個~以上の `0020^U `SPACE^cn, `~ASCII大小無視$で `base64^l に合致する文字列 ◎終 …ならば: ◎ If mimeType ends with U+003B (;), followed by zero or more U+0020 SPACE, followed by an ASCII case-insensitive match for "base64", then:
- %文字列~本体 ~LET `同型に復号する$( %本体 ) ◎ Let stringBody be the isomorphic decode of body.
- %本体 ~SET `~forgiving-base64復号する$( %文字列~本体 ) ◎ Set body to the forgiving-base64 decode of stringBody.
- ~IF[ %本体 ~EQ `失敗^i ] ⇒ ~RET `失敗^i ◎ If body is failure, then return failure.
- %~MIME型 ~SET %S ◎ Remove the last 6 code points from mimeType. ◎ Remove trailing U+0020 SPACE code points from mimeType, if any. ◎ Remove the last U+003B (;) code point from mimeType.
- ~IF[ %~MIME型 の先頭の符号位置 ~EQ `003B^U `;^smb ] ⇒ %~MIME型 ~SET 次を順に連結した結果 ⇒# `text/plain^l, %~MIME型 ◎ If mimeType starts with U+003B (;), then prepend "text/plain" to mimeType.
- %~MIME型~record ~LET `~MIME型を構文解析する$( %~MIME型 ) ◎ Let mimeTypeRecord be the result of parsing mimeType.
- ~IF[ %~MIME型~record ~EQ `失敗^i ] ⇒ %~MIME型~record ~SET `text/plain;charset=US-ASCII^c ◎ If mimeTypeRecord is failure, then set mimeTypeRecord to text/plain;charset=US-ASCII.
- ~RET 次のようにされた新たな`~data_URL構造体$ ⇒# `~MIME型$dU ~SET %~MIME型~record, `本体$dU ~SET %本体 ◎ Return a new data: URL struct whose MIME type is mimeTypeRecord and body is body.
背景情報
`この節(および その下位節)は規範的でない。^em ◎ This section and its subsections are informative only.
~HTTP~header層の~~区分
~fetchingの目的においては、次に挙げる層がある:
- ~API層 ⇒ 開発者は、この層において~headerを設定できる(概して, `Request$I ~objを通して)。
- 早期~fetch層(~HTMLの `img^e 要素, ~CSSの `background-image^css ~propなど) ⇒ `Accept$h, `Accept-Language$h は、(概して,~UAにより)この層にて設定される。
- ~sw層 ⇒ ~API層と同様に,開発者は、この層において~headerを設定できる。
- ~network&~cache層 ⇒ `Accept-Encoding$h, `Host$h, `Referer$h など,~UAにより制御される他のほとんどの~headerは、この層において設定される。
`禁止~header名$については、開発者が制御できる部分はほとんどないが, `Accept$h を制御したり, `Referer$h を拘束する/省略させる手段【`~referrer施策$】はある。
◎ For the purposes of fetching, there is an API layer (HTML’s img, CSS' background-image), early fetch layer, service worker layer, and network & cache layer. `Accept` and `Accept-Language` are set in the early fetch layer (typically by the user agent). Most other headers controlled by the user agent, such as `Accept-Encoding`, `Host`, and `Referer`, are set in the network & cache layer. Developers can set headers either at the API layer or in the service worker layer (typically through a Request object). Developers have almost no control over forbidden headers, but can control `Accept` and have the means to constrain and omit `Referer` for instance.~HTTP~redirectの不可分な取扱い
~redirect(`応答$のうち,[ その`状態s$rs, または その`内部~応答$の`状態s$rs ]が `~redirect状態s$であるもの)は、~APIには公開されない。 仮に~redirectを公開したなら,~XSS攻撃を通して情報が漏洩されることになる。 ◎ Redirects (a response whose status or internal response’s (if any) status is a redirect status) are not exposed to APIs. Exposing redirects might leak information not otherwise available through a cross-site scripting attack.
[ `HttpOnly^bl 付きの `Cookie$h ]が含まれる~URL(例えば `https://example.org/auth^s )への~fetchが,秘匿情報を包含する~URL(例えば `https://other-origin.invalid/4af955781ea1c84a3b11^s )への~redirectになることもある。 仮に~redirectが公開されたなら、この秘匿情報は,~XSS攻撃により入手されることになる。 ◎ A fetch to https://example.org/auth that includes a Cookie marked HttpOnly could result in a redirect to https://other-origin.invalid/4af955781ea1c84a3b11. This new URL contains a secret. If we expose redirects that secret would be available through a cross-site scripting attack.
安全な~CORS~protocolを設定しておくための基本
IP 認証や~firewallを通して~dataが保護されている資源(不幸なことに,未だに ありふれている)に対する`~CORS~protocol$の利用は、安全でない。 (`~CORS~protocol$を考案する必要が生じた理由は、それである。) ◎ For resources where data is protected through IP authentication or a firewall (unfortunately relatively common still), using the CORS protocol is unsafe. (This is the reason why the CORS protocol had to be invented.)
しかしながら、次の`~header$を利用している場合は安全である: 【!otherwise】 ◎ However, otherwise using the following header is safe:
Access-Control-Allow-Origin: *
資源が~cookieや~HTTP認証に基づく追加的な情報を公開するときでも、上の`~header$の利用は,それを露呈しない。 これは、 curl や wget などにより すでに共有されているかのごとく,資源を `XMLHttpRequest$I などの~APIと共有する。 ◎ Even if a resource exposes additional information based on cookie or HTTP authentication, using the above header will not reveal it. It will share the resource with APIs such as XMLHttpRequest, much like it is already shared with curl and wget.
したがって,言い換えれば、当の資源が[ ~webに接続している どの機器からも( curl や wget などを利用して)~accessし得るもの ]でないならば,上述の`~header$は含まれない。 ~accessし得る場合、それを含めることは,まったく申し分ない。 ◎ Thus in other words, if a resource cannot be accessed from a random device connected to the web using curl and wget the aforementioned header is not to be included. If it can be accessed however, it is perfectly fine to do so.
~CORS~protocolと~HTTP~cache
`~CORS~protocol$の要件が,[ `Access-Control-Allow-Origin$hを[ `*^bl / 静的な`生成元$ ]に設定する ]より複雑なものである場合、 `Vary$h を利用することになる。 `HTML$r `HTTP$r `HTTP-SEMANTICS$r `HTTP-COND$r `HTTP-CACHING$r `HTTP-AUTH$r ◎ If CORS protocol requirements are more complicated than setting `Access-Control-Allow-Origin` to * or a static origin, `Vary` is to be used. [HTML] [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]
Vary: Origin
~serverは、ある資源において[ その資源への要請が`~CORS要請$である場合に限り,応答~内に `Access-Control-Allow-Origin$h を送信する ]よう環境設定されているとする。 このとき、 `Vary$h が`利用されない^emと何が起こるか考える。 ~UAが その資源への非`~CORS要請$に対する応答を受信したとき(例えば、`~navi要請$の結果として)、~UAは, `Access-Control-Allow-Origin$h を欠く応答 — “非~CORS応答” — を~cacheすることになる。 ~UAは、後で同じ資源への`~CORS要請$に遭遇した場合にも,この “非~CORS応答” を利用することになる。 ◎ In particular, consider what happens if `Vary` is not used and a server is configured to send `Access-Control-Allow-Origin` for a certain resource only in response to a CORS request. When a user agent receives a response to a non-CORS request for that resource (for example, as the result of a navigation request), the response will lack `Access-Control-Allow-Origin` and the user agent will cache that response. Then, if the user agent subsequently encounters a CORS request for the resource, it will use that cached response from the previous non-CORS request, without `Access-Control-Allow-Origin`.
同じ局面で `Vary: Origin^bl を利用した場合、 `Access-Control-Allow-Origin$h を含む応答を~UAに`~fetch$させ,~cacheされた “非~CORS応答” が利用されることはなくなる。 ◎ But if `Vary: Origin` is used in the same scenario described above, it will cause the user agent to fetch a response that includes `Access-Control-Allow-Origin`, rather than using the cached response from the previous non-CORS request that lacks `Access-Control-Allow-Origin`.
しかしながら,~serverは、ある資源に対し, `Access-Control-Allow-Origin$h を[ `*^bl / 静的な`生成元$ ]に設定する場合には、その資源~用の応答~内には — `~CORS要請$かどうかを問わず — 常に `Access-Control-Allow-Origin$h を送信するよう環境設定して, `Vary$h は利用しないこと。 ◎ However, if `Access-Control-Allow-Origin` is set to * or a static origin for a particular resource, then configure the server to always send `Access-Control-Allow-Origin` in responses for the resource — for non-CORS requests as well as CORS requests — and do not use `Vary`.
謝辞
この仕様の策定に貢献された次の方々に感謝する:
`_acks1@