目標
~web~platformにおける~fetchingを統一化するため、この仕様は,いくつかの~algoと仕様に取って代わる: ◎ To unify fetching across the web platform this specification supplants a number of algorithms and specifications:
- ~HTML標準の[ `fetch^en, および `potentially CORS-enabled fetch^en ]~algo `HTML$r 【過去の~HTML仕様に定義されていた fetch, potentially CORS-enabled fetch】 ◎ HTML Standard’s fetch and potentially CORS-enabled fetch algorithms [HTML]
- CORS `CORS$r 【 `Cross-Origin Resource Sharing^en — “生成元~間をまたがる資源の共有”】 ◎ CORS [CORS]
- ~HTTP `Origin$h ~headerの意味論 `ORIGIN$r ◎ HTTP `Origin` header semantics [ORIGIN]
~fetchingの統一化は、次に対する,一貫した取扱いを供する:
- 各種~URL~scheme
- ~redirect
- 非同一生成元( `cross-origin^en, “生成元~間をまたがる” )の意味論 【`同一生成元$( `same-origin^en )の否定の意味でもある。】
- CSP `CSP$r 【 “`Content Security Policy^en” ( “内容保安施策” )の略語。この訳では、一貫してこの略語を利用する。】
- ~sw `SW$r
- 混在~内容( `Mixed Content^en ) `MIX$r
- `Referer$h ~header `REFERRER$r
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応答~status~code / `~CSP指令$ / `~promise型$idl ~obj用の各種成句(`却下する$, 等々) ]には、それを定義する仕様(和訳)へのリンクを追加している(これらのリンクは、原文~仕様にはあてがわれていない)。
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により改変された~ABNFを意味する(特に, # の追加 【 RFC7230, 7 節】 )。 ◎ ABNF means ABNF as modified by HTTP (in particular the addition #).
`資格証@ は、[ ~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]
この標準により`~queueされ$る`~task$は、次のいずれかとして,~~記される: ◎ Tasks that are queued by this standard are annotated as one of:
- `要請の本体を処理する@ ◎ process request body
- `要請の本体終端を処理する@ ◎ process request end-of-body
- `応答を処理する@ ◎ process response
- `応答の本体終端を処理する@ ◎ process response end-of-body
- `応答の~doneを処理する@ ◎ process response done
【 これらの~task( “〜を処理する” )は、この仕様に定義される~fetchingを利用する他の仕様(例えば `XHR$r )が,個々の必要に応じて それぞれに定義するものになる(一種の callback )。 】
`要請$ %要請 上で[ 所与の %演算 を走らす ]ための `~fetch~taskを~queueする@ ときは、次を走らす: ◎ To queue a fetch task on request request to run an operation, run these steps:
- ~IF[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ ~RET ◎ If request’s client is null, terminate these steps.
- `~network用~task源$から %要請 の`~client$rqの`担当の~event-loop$enV上に, %演算 を走らす`~taskを~queueする$ ◎ Queue a task to run an operation on request’s client’s responsible event loop using the networking task source.
所与の %要請 に対する `~fetch要請~done~taskを~queueする@ ときは、 %要請 上で[ `要請の本体終端を処理する$ ]ための`~fetch~taskを~queueする$。 ◎ To queue a fetch-request-done task, given a request, queue a fetch task on request to process request end-of-body for request.
`整数を直列化する@ ときは、所与の整数を最短の 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, `filesystem^l ◎ A local scheme is a scheme that is "about", "blob", "data", or "filesystem".
`~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が `~network~scheme@ である ⇒# `ftp^l, `~HTTP_S~scheme$ ◎ A network scheme is a scheme that is "ftp" or an HTTP(S) scheme.
次に挙げる`~scheme$urlが `~fetch~scheme@ である ⇒# `about^l, `blob^l, `data^l, `file^l, `filesystem^l, `~network~scheme$ ◎ A fetch scheme is a scheme that is "about", "blob", "data", "file", "filesystem", or a network scheme.
注記: `~network~scheme$, `~HTTP_S~scheme$, `~fetch~scheme$ は~HTMLからも利用される。 `HTML$r ◎ HTTP(S) scheme, network scheme, and fetch scheme are also used by HTML. [HTML]
`応答~URL@ は、`~URL$のうち,[ 実装は`素片$urlを格納する必要はない ]ものである — それは、~APIには決して公開されないので。 そのような`~URLを直列化する$ときには、 %素片は除外する~flag は `素片は除外する^i にされる† — すなわち実装は、それにかまわず,`素片$urlを格納できる。 【† この仕様が定義する~APIにおいては、 `response.url$m 属性。】 ◎ A response URL is a URL for which implementations need not store the fragment as it is never exposed. When serialized, the exclude fragment flag is set, meaning implementations can store the fragment nonetheless.
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空白~byte列@ は、それを成す どの~byte %byte も次を満たす~byte列である ⇒ %byte ~IN { `09^X, `0A^X, `0D^X, `20^X } ◎ The HTTP whitespace bytes are 0x09, 0x0A, 0x0D, and 0x20.
`~HTTPS状態~値@ は、次のいずれかをとる ⇒# `none^l, `deprecated^l, `modern^l ◎ An HTTPS state value is "none", "deprecated", or "modern".
注記: ~HTTPS越しに送達される`応答$の`~HTTPS状態$rsは、概して, `modern^l に設定される。 ~UAは、過渡期においては `deprecated^l を利用できる。 例えば[ ~hash関数 / 弱い暗号suite / "Internal Name" 用の証明書 / 有効期間が長過ぎる証明書 ]の~supportを除去するまでの間など。 ~UAが,正確にどの~~程度まで `deprecated^l を利用できるかは、この仕様では定義されない。 `環境~設定群~obj$は、概して`応答$から その`~HTTPS状態$enVを送達する。 ◎ A response delivered over HTTPS will typically have its HTTPS state set to "modern". A user agent can use "deprecated" in a transition period. E.g., while removing support for a hash function, weak cipher suites, certificates for an "Internal Name", or certificates with an overly long validity period. How exactly a user agent can use "deprecated" is not defined by this specification. An environment settings object typically derives its HTTPS state from a response.
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大小無視$で合致するならば[ %M を`~byte大文字~化$した結果 ] / ~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とする。 【~HTTPの文脈では,~messageの~header節を表現する。】 ◎ A header list is a list of zero or more headers. It is initially the empty list.
注記: `~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.
所与の`名前$hd(または`~byte列$) %名前 を `名前に持つ~header@ とは、`~header$であって,その`名前$hdが[ `~byte大小無視$で %名前 に合致する ]ものを指す。
【 言い換えれば、`~header$の`名前$hdは,常に`~byte大小無視$で比較される — 元々の~HTTP~protocolが,~header名の文字大小を区別しないので。 】【 この用語は、他所を簡便に記すために,この訳にて導入している。 】
[ そのような`~header$を所与の`~list$ %~list が`包含して$いる ]という条件は、単に, “%~list 内に %名前 を`名前に持つ~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$は %名前 を `包含する@hd” という句として定義されているが、この訳(および,この仕様を参照している和訳)では,この用語 “包含する” は利用せず,もっぱら`名前に持つ~header$を用いて等価に記すことにする。 】
`~header~list$ %~list に `~headerを付加する@ ときは、所与の組 ( `名前$hd %name / `値$hd %value ) に対し,次を走らす: ◎ To append a name/value (name/value) pair to a header list (list), run these steps:
-
~IF[ %~list 内に[ %name を`名前に持つ~header$ ]は在る ] ⇒ %name ~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$( %name / %value ) を`付加する$ ◎ Append a new header whose name is name and value is value to list.
`~header~list$ %~list から `~headerを削除する@ ときは、所与の ( `名前$hd %name ) に対し,次を走らす ⇒ %~list から[ %name を`名前に持つ~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を設定する@ ときは、所与の組 ( `名前$hd %name / `値$hd %value ) に対し,次を走らす: ◎ To set a name/value (name/value) pair in a header list (list), run these steps:
- ~IF[ %~list 内に[ %name を`名前に持つ~header$ ]は在る ] ⇒ そのような`~header$のうち ⇒# 最初のものに対しては,その`値$hd ~SET %value; 他のものは, %~list から`除去する$ ◎ If list contains name, then set the value of the first such header to value and remove the others.
- ~ELSE ⇒ %~list に `新たな~header$( %name / %value ) を`付加する$ ◎ Otherwise, append a new header whose name is name and value is value to list.
`~header~list$ %~list 内で `~headerを結合する@ ときは、所与の組 ( `名前$hd %name / `値$hd %value ) に対し,次を走らす: ◎ To combine a name/value (name/value) pair in a header list (list), run these steps:
- ~IF[ %~list 内に[ %name を`名前に持つ~header$ ]は在る ] ⇒ そのような`~header$のうち,最初のものに対し ⇒ その`値$hdの末尾に[ `2C^X, `20^X, %value ]を順に付加する ◎ 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$( %name / %value ) を`付加する$ ◎ 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~list$ %~header~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.
- %名前~list ~LET [[[ %~header~list 内の`~header$すべての`名前$hd ]を,それぞれ`~byte小文字~化$した結果 ]から,重複する名前は除去した結果 ]を字句順に整列した結果 ◎ Let names be all the names of the headers in list, byte-lowercased, with duplicates removed, and finally sorted lexicographically.
-
%名前~list 内の ~EACH( %名前 ) に対し: ◎ For each name in names:
- %値 ~LET %~header~list 内の %名前 に対する`結合-済みの値$hd ◎ Let value be the combined value given name and list.
- %結果~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 ]の組, あるいは それを意図して与えられる値の組は、 “( %名前 / %値 )” のように,スラッシュで区切った上で丸括弧で括られて記される。 】
-
`名前$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空白~byte列$はない。 ◎ Has no leading or trailing HTTP whitespace bytes.
- ~byte `00^X, `0A^X, `0D^X は包含しない。 ◎ Contains no 0x00, 0x0A or 0x0D bytes.
注記: `値$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~list$ %~header~list 内の 所与の`名前$hd %名前 に対する `結合-済みの値@hd とは、 %~header~list 内の[ %名前 を`名前に持つ~header$ ]すべての`値$hdを互いに[ `2C^X `20^X ]並びで区切って順に連結したものである。 ◎ A combined value, given a name (name) and header list (list), is 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.
`~CORS安全な要請~header@ とは、次のいずれかを満たす`~header$である: ◎ A CORS-safelisted request-header is a header whose name is a byte-case-insensitive match for one of
- 次のいずれかを`名前に持つ~header$である ⇒# `Accept$h, `Accept-Language$h, `Content-Language$h ◎ • `Accept` • `Accept-Language` • `Content-Language`
-
次の両者を満たす:
- `Content-Type$h を`名前に持つ~header$である
- ~headerから`値を抽出-$した結果の~MIME型から~parameterは除外した部分 ~IN { `application/x-www-form-urlencoded^bl, `multipart/form-data^bl, `text/plain^bl }
-
次の両者を満たす:
- 次のいずれかを`名前に持つ~header$である ⇒# `DPR$h, `Downlink$h, `Save-Data$h, `Viewport-Width$h, `Width$h
- ~headerから`値を抽出-$した結果 ~NEQ `失敗^i
注記: ~CORS安全とされる `Content-Type$h ~headerには,制限付きの例外がある — ~CORS~protocol例外 節を見よ。 ◎ There are limited exceptions to the `Content-Type` header safelist, as documented in CORS protocol exceptions.
`~CORS非~wildcard要請~header名@ は、[ `Authorization^bl に`~byte大小無視$で合致する`名前$hd ]である。 ◎ A CORS non-wildcard request-header name is a byte-case-insensitive match for `Authorization`.
`特権的~no-cors要請~header名@ は、[ 次に挙げるいずれかの`名前$hdに`~byte大小無視$で合致する`名前$hd ]である: ◎ A privileged no-cors request-header name is a header name that is a byte-case-insensitive match for one of
- `Range$h
注記: これらは、特権的~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に`~byte大小無視$で合致する`名前$hd ]である: ◎ A CORS-safelisted response-header name, given a CORS-exposed header-name list list, is a header name that is a byte-case-insensitive match for one of
- `Cache-Control$h
- `Content-Language$h
- `Content-Length$h
- `Content-Type$h
- `Expires$h
- `Last-Modified$h
- `Pragma$h
- %~list 内の`禁止~応答~header名$でない`値$hd ◎ Any value in list that is not a forbidden response-header name.
次に挙げる`名前$hdは、 `禁止~header名@ とされる: ◎ A forbidden header name is a header name that is\
-
次に挙げるいずれかに`~byte大小無視$で合致するもの: ◎ a byte-case-insensitive match for one of
- `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である: ◎ A forbidden response-header name is a header name that is a byte-case-insensitive match for one of:
- `Set-Cookie$h
- `Set-Cookie2^h
`~headerから値を抽出する@ ときは、所与の ( `~header$ %~header ) に対し,次を走らす: ◎ To extract header values given a header header, run these steps:
- %~header の`値$hdを[ %~header の`名前$hd用の`~ABNF$ ]に従って構文解析する 【 RFC7230, 2.2.4 節】 ◎ 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の取扱いが必要な場合†2、事前に~~目的の`~header$を抽出すること。 ◎ If different error handling is needed, extract the desired header first.
【† — RFC7230, 2.2.2 節 】【†2 — 同じ 2.2.2 節の注記を指しているようにも思われるが、他にも該当する事例はあるかもしれない。 】
- %値~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.
【† %名前 用の`~ABNF$が複数個の値を許容しない, かつ %名前 を`名前に持つ~header$は`~header~list$内に複数~存在できない場合、この手続きを呼出している箇所では,結果の %値~list は暗黙的に その最初の値と同一視されている。 】
`~MIME型を抽出する@ ときは、所与の ( `~header~list$ %~header~list ) に対し,次を走らす: ◎ To extract a MIME type from a header list (headers), run these steps:
- %~MIME型 ~LET `~header~listから値を抽出する$( %~header~list, `Content-Type$h ) ◎ Let mimeType be the result of extracting header list values given `Content-Type` and headers.
- ~IF[ %~MIME型 ~IN { ~NULL, `失敗^i } ] ⇒ ~RET 空~byte列 ◎ If mimeType is null or failure, then return the empty byte sequence.
- ~RET %~MIME型 を`~byte小文字~化$した結果 ◎ Return mimeType, byte-lowercased.
`既定の 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. ~status
`~status@ は~codeである。 ◎ A status is a code.
次に挙げる`~status$は、 `~null本体~status@ であるとされる ⇒# `101$st, `204$st, `205$st, `304$st ◎ A null body status is a status that is 101, 204, 205, or 304.
次の範囲の`~status$は、 `~ok~status@ であるとされる ⇒ `200^st 〜 `299^st ◎ An ok status is any status in the range 200 to 299, inclusive.
次に挙げる`~status$は、 `~redirect~status@ であるとされる ⇒# `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
- ~NULL または `~ReadableStream$ ~obj。 ◎ A stream (null or a ReadableStream object).
- `伝送-済み~byte数@bd
- 整数 — 初期~時は 0 。 ◎ A transmitted bytes (an integer), initially 0.
- `総~byte数@bd
- 整数 — 初期~時は 0 。 ◎ A total bytes (an integer), initially 0.
- `~source@bd
- 初期~時は ~NULL 。 ◎ A source, initially null.
【 ~HTTPの文脈では、本体は,~messageの~payload本体を表現する。 】
`本体$ %本体 は、次のいずれかを満たすならば, `~done@bd であるという:
- %本体 ~EQ ~NULL
- %本体 の`~stream$bd は[ `~closeされた$RS / `~errorした$RS ]
`本体を待機する@ ときは、所与の ( `本体$ %本体 ) に対し %本体 が`~done$bdになるまで,待機する ◎ To wait for a body body, wait for body to be done.
`本体を~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.
`内容~符号法sを取扱う@ ときは、所与の ( 内容~符号法s† %符号法s, ~byte列 %~byte列 ) に対し,次を走らす 【†content codings — 複数の内容~符号法が重ねて適用されることもあり得る】 : ◎ 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 ~HTTPに従って, %~byte列 を %符号法s で復号した結果は[ ~errorでないならば その結果 / ~ELSE_ `失敗^i ] `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の間に `GET$hm に更新され得る。 ◎ 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 に対応する。 】
- `局所~URLのみ~flag@( ~OFF )
- ~flag値。 ◎ A request has an associated local-URLs-only flag. Unless stated otherwise it is unset.
- `~sandboxed-storage-area-URLs~flag@( ~OFF )
- ~flag値。 ◎ A request has an associated sandboxed-storage-area-URLs 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( ~OFF )
- ~flag値。 ◎ 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により ~ON にされる。 これは、~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 または`本体$。 ◎ A request has an associated body (null or a body). Unless stated otherwise it is null.
- 注記: これは、`~HTTP~fetch$にて述べるように,~redirectの間に ~NULL に更新され得る。 ◎ This can be updated during redirects to null as described in HTTP fetch.
- `~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.
- `~target~client~id@rq ( 空~文字列 )
- 文字列。 ◎ A request has an associated target 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~flag@rq( ~OFF )
- ~flag値。 ◎ A request has an associated keepalive flag. Unless stated otherwise it is unset.
- 注記: これを利用すれば、要請は`環境~設定群~obj$の外で残存できるようになる — 例えば[ `navigator.sendBeacon()$m ~method/~HTML `img$e 要素 / 【~CSPの違反~報告】 ]は、この~flagを ~ON にする。 この~flagが ~ON にされた要請には、追加の処理~要件が課される。 ◎ 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, `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", "image", "manifest", "object", "paintworklet", "report", "script", "serviceworker", "sharedworker", "style", "track", "video", "worker", or "xslt". Unless stated otherwise it is the empty string.
-
`要請$の`行先$rqのうち,次に挙げるものは `~scriptに類する@ とされる ⇒# `script^l, `audioworklet^l, `paintworklet^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 `document^l `child-src$dir ~HTMLの `iframe$e, `frame$e 要素 "" `connect-src$dir `navigator.sendBeacon()$m, `EventSource$I, ~HTMLの `ping=""^a, `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の`担当の閲覧文脈$enV ]の各 `先祖~閲覧文脈$についても検査する必要がある。 ◎ CSP will also need to check request’s client’s responsible 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.
- `~client~hint~list@rq( 空~list )
- `~client~hint~list$。 ◎ A request has an associated client hints list, which is a client-hints list. Unless stated otherwise, it is the empty list.
- 注記: これは、[ `環境~設定群~obj$に結付けられている~client~hint~list ]を上書きするために利用される。 `CLIENT-HINTS$r ◎ This will be used to override a client hints list associated with an environment settings object. [CLIENT-HINTS]
- `同期~flag@rq( ~OFF )
- ~flag値。 ◎ A request has an associated synchronous flag. Unless stated otherwise it is unset.
- `~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
- 要請を`~CORS要請$にする。 要請された資源が`~CORS~protocol$に解されなかった場合、~fetchは`~network~error$を返すことになる。 ◎ Makes the request a CORS request. Fetch will return a network error if the requested resource does not understand 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( ~OFF )
- ~flag値。 ◎ A request has an associated use-CORS-preflight flag. Unless stated otherwise, it is unset.
-
注記: `~CORS予行~要請$が生じるための条件にはいくつかあるが、[ `~CORS予行~利用~flag$rq ~EQ ~ON ]であることは,その 1 つである。 この~flagは、次のいずれかの場合には ~ON にされる:
- `XMLHttpRequestUpload$I ~obj上に登録されている~event~listenerがある
- 要請に `ReadableStream$I ~objが利用されている
- `資格証~mode@rq( `omit^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 "omit".
-
注記: これらの値の意味は:
- `omit^l
- この要請からは、資格証を除外する。 ◎ Excludes credentials from this request.
- `same-origin^l
- 同一生成元~URLにされた要請には、資格証を含める。 ◎ Include credentials with requests made to same-origin URLs.
- `include^l
- この要請には、常に資格証を含める。 ◎ Always includes credentials with this request.
- 注記: `要請$の`資格証~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( ~OFF )
- ~flag値。 ◎ 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を検分する。 ~cache内に[ 要請に合致する`新鮮$な応答 ]が在れば、それが利用されることになる。 無ければ、`非新鮮$な応答が[ 在れば `条件付き要請$ / 無ければ 通常の要請 ]を作成した上で,対する応答で~HTTP~cacheを更新する。 `HTTP$r `HTTP-SEMANTICS$r `HTTP-COND$r `HTTP-CACHING$r `HTTP-AUTH$r ◎ Fetch will inspect the HTTP cache on the way to the network. If there is a fresh response it will be used. If there is a stale response a conditional request will be created, and a normal request otherwise. It then updates the HTTP cache with the response. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH]
- `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に出くわしたときには、手動で追従できるよう,`不透明redirect絞込み応答$を検索取得する。 ◎ Retrieves an opaque-redirect filtered response when a request is met with a redirect so that the redirect can be followed manually.
- `完全性~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/~stylesheet が 構文解析-時に挿入されたものかどうか を表す。 】
- 注記: `要請$の[ `暗号用~nonce~metadata$rq, `構文解析器~metadata$rq ]は,一般に、`要請$を作成する責を負う~HTML要素~上の各種[ 属性, ~flag ]から拡充される。 これらは、~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( ~OFF )
- ~flag値。 ◎ 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( ~OFF )
- ~flag値。 ◎ 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( ~OFF )
- ~flag値。 ◎ A request has an associated tainted origin flag. Unless stated otherwise, it is unset.
- `~url~list@rq( « `要請$の`~url$rqの複製 » )
- 一個~以上の`~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".
- 【 この要請に対する応答は、何に “~~染まる” か。 保安~用の制限を与える(`絞込み応答$の種類として反映されることになる)。 】
- `~done~flag@rq( ~OFF )
- ~flag値。 ◎ A request has an associated done flag. Unless stated otherwise, it is unset.
注記: `要請$の[ `~tainted生成元~flag$rq, `~url~list$rq, `現在の~url$rq, `~redirect数$rq, `応答~tainting$rq, `~done~flag$rq ]は,`~fetch$ ~algoの内部状態管理に利用される。 ◎ A request’s tainted origin flag, url list, current url, redirect count, response tainting, and done 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.
`~naviまたは下位資源のいずれかになり得る要請@ とは、次のいずれかを`行先$rqとする`要請$である ⇒# `object^l, `embed^l ◎ A potential-navigation-or-subresource request is a request whose destination is "object" or "embed".
`非~下位資源~要請@ とは、次のいずれかを`行先$rqとする`要請$である ⇒# `document^l, `report^l, `serviceworker^l, `sharedworker^l, `worker^l ◎ A non-subresource request is a request whose destination is "document", "report", "serviceworker", "sharedworker", or "worker".
【 `下位資源~要請$ではないが、論理的な否定 — すべての要請のうち,下位資源~要請ではないもの — でもないことに注意。 】
`~navi要請@ とは、次を`行先$rqとする`要請$である ⇒# `document^l ◎ A navigation request is a request whose destination is "document".
注記: これらの用語の用法については handle 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 ~ON ] ⇒ ~RET `null^bl ◎ If request’s tainted origin flag is set, then return `null`.
- ~RET `同型に符号化する$( `生成元を直列化する$( %要請 の`生成元$rq ) ) ◎ Return request’s origin, serialized and 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.
`要請~用の本体を伝送する@ ときは、所与の ( `要請$ %要請 ) に対し,次を走らす: ◎ To transmit body for a request request, run these steps:
- %本体 ~LET %要請 の`本体$rq ◎ Let body be request’s body.
- ~IF[ %本体 ~EQ ~NULL ] ⇒# %要請 上で`要請の本体終端を処理する$ための`~fetch~taskを~queueする$; ~RET ◎ If body is null, then queue a fetch task on request to process request end-of-body for request and abort these steps.
-
%読取器 ~LET `読取器を取得する$RS( %本体 の`~stream$bd ) ◎ Let reader be the result of getting a reader from body’s stream.
注記: この演算は例外を投出し得ない。 ◎ This operation cannot throw an exception.
- %読取り ~LET %本体 の`~stream$bdから %読取器 で`~chunkを読取った$RS結果 ◎ Let read be the result of reading a chunk from body’s stream with reader.
- ~RET — ただし、以降は`並列的$に走らす ◎ In parallel, while true:
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
~WHILE 無条件: ◎ ↑
- %読取り が充足されるか却下されるまで待機する ◎ Wait for read to be fulfilled or rejected.
-
~IF[ %読取り は次を満たす 値 %O で充足された ]…:
- ~objである
- `done^c ~prop ~EQ ~F
- `value^c ~propは `Uint8Array$I ~objである
…ならば:
◎ If read is fulfilled with an object whose done property is false and whose value property is a Uint8Array object, then run these steps:- %~byte列 ~LET %O の `value^c ~propが表現する`~byte列$ ◎ Let bs be the byte sequence represented by the Uint8Array object.
-
%~byte列 を伝送する — 1 個 以上の~byteが伝送される度に ⇒# %本体 の`伝送-済み~byte数$bd ~INCBY 伝送された~byte数; %要請 上で`要請の本体を処理する$ための`~fetch~taskを~queueする$ ◎ Transmit bs. Whenever one or more bytes are transmitted, increase body’s transmitted bytes by the number of transmitted bytes and queue a fetch task on request to process request body for request.
注記: %~byte列 が全部的に伝送されるまでは、この段に留まり続ける。 ◎ This step blocks until bs is fully transmitted.
- %読取り ~SET %本体 の`~stream$bdから %読取器 で`~chunkを読取った$RS結果 ◎ Set read to the result of reading a chunk from body’s stream with reader.
- ~CONTINUE
- ~IF[ %読取り は[ `done^c ~prop ~EQ ~T ]を満たす~obj %O で充足された ] ⇒# %要請 上で`要請の本体終端を処理する$ための`~fetch~taskを~queueする$; ~BREAK ◎ Otherwise, if read is fulfilled with an object whose done property is true, then queue a fetch task on request to process request end-of-body for request and abort these in-parallel steps.
- ~IF[ %読取り は事由 `AbortError$E 例外で却下された ] ⇒ 進行中の~fetchを`終了させる$( `中止~flag^i ~SET ~ON ) ◎ Otherwise, if read is rejected with an "AbortError" DOMException, terminate the ongoing fetch with the aborted flag set.
- ~ELSE ⇒ 進行中の~fetchを`終了させる$() ◎ Otherwise, terminate the ongoing fetch.
- 前~段が`中止されたときは$、この並列的な段も中止する ◎ If aborted, then abort these in-parallel steps.
`範囲~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 個の論理的な資源に組合せる特色機能は、歴史的に保安~bugの源になる。 部分的~応答に対処する特色機能に対する保安~考査を探されたし。 ◎ 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.
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( ~OFF )
- ~flag値。 ◎ A response can have an associated aborted flag, which is initially unset.
- 注記: これは、 ~ON ならば 開発者/末端利用者 が要請を意図的に中止したことを指示する。 ◎ 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 response URL in response’s url list and null if response’s url list is the empty list.
- `~url~list@rs( 空~list )
- 0 個~以上の`応答~URL$からなる~list。 ◎ A response has an associated url list (a list of zero or more response URLs). Unless stated otherwise, it is the empty list.
- 注記: 最後の`応答~URL$を除いて,この~listは~scriptには公開されない。 そうすると `~HTTP~redirectの不可分的な取扱い$に違反するので。 ◎ Except for the last response URL, if any, a response’s url list cannot be exposed to script. That would violate atomic HTTP redirect handling.
- `~status@rs( `200$st )
- `~status$。 ◎ A response has an associated status, which is a status. Unless stated otherwise it is 200.
- 【 ~HTTPの文脈では,応答の status code を表現する。 】
- `~status~message@rs( 空`~byte列$ )
- `~byte列$。 ◎ A response has an associated status message. Unless stated otherwise it is the empty byte sequence.
- 注記: HTTP/2 接続~越しの応答においては、その~status~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 を表現する。 】
- `~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.
- `~trailer@rs(空~list)
- `~header~list$。 ◎ A response has an associated trailer (a header list). Unless stated otherwise it is empty.
- 【 ~trailer `HTTP$r を成す~headerたちを表現する。 】
- `~trailerは失敗した~flag@rs( ~OFF )
- ~flag値。 ◎ A response has an associated trailer failed flag, which is initially unset.
- `~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]
- `~HTTPS状態@rs( `none^l )
- `~HTTPS状態~値$。 ◎ A response has an associated HTTPS state (an HTTPS state value). Unless stated otherwise, it is "none".
- `~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 ( ~OFF )
- ~flag値。 ◎ 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.
- `所在~URL@rs ( ~NULL †)
- 次のいずれか ⇒# ~NULL, `失敗^i, `~URL$ ◎ A response can have an associated location URL (null, failure, or a URL). Unless specified otherwise, response has no location URL.
- 注記: この概念は、~Fetchおよび~HTMLの~navigate~algoにて,~redirectを取扱うために利用される。 それは、一度だけ, かつ一貫するように `Location^h ~headerから`値を抽出-$することを確保する。 `HTML$r ◎ This concept is used for redirect handling in Fetch and in HTML’s navigate algorithm. It ensures `Location` has its value extracted consistently and only once. [HTML]
- 【† 原文には,既定~値は “`has no location URL^en” (所在~URLは “ない” )という句として記されているが、おそらく, ~NULL を指している( ~NULL が一般に “ないこと” を表すことに加え、この用語を参照している~HTMLの`~navi$~algoも含め,そのような句を所在~URLに用いている箇所は、ここ以外に無いので)。 】
次を満たす`応答$は、 `中止~network~error@ と呼ばれる ⇒ [ `~network~error$である ]~AND[ `中止~flag$rs ~EQ ~ON ] ◎ 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$は,常に次をすべて満たすようにされる:
- `~status$rs ~EQ 0
- `~status~message$rs ~EQ 空~byte列
- `~header~list$rsは空である
- `本体$rs ~EQ ~NULL
- `~trailer$rsは空である
`絞込み応答@ とは、`~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から[ `名前$hdが`禁止~応答~header名$である`~header$ ]は除外したものである
`~CORS絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `cors^l
- `~header~list$rsは、`内部~応答$の`~CORSに公開される~header名~list$rsから[ `名前$hdが`~CORS安全な応答~header名$でない,`~header$ ]は除外したものである
- `~trailer$rsは空である
`不透明な絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `opaque^l
- `~url~list$rsは空である
- `~status$rs ~EQ 0
- `~status~message$rs ~EQ 空~byte列
- `~header~list$rsは空である
- `本体$rs ~EQ ~NULL
- `~trailer$rsは空である
`不透明redirect絞込み応答@ とは、次をすべて満たすようにされた`絞込み応答$である:
- `種別$rs ~EQ `opaqueredirect^l
- `~status$rs ~EQ 0
- `~status~message$rs ~EQ 空~byte列
- `~header~list$rsは空である
- `本体$rs ~EQ ~NULL
- `~trailer$rsは空である
`不透明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.
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-AUTH$r 2.2 節 】 ◎ 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と, それに類する追跡~機能性 ]が一緒に消去されることを,許容する~SHOULDである。 ◎ 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 ~OFF ]~OR[ `~keepalive~flag$rq ~EQ ~OFF ]]を満たす ] ⇒ %記録 の`~fetch$fgを`終了させる$() ◎ When a fetch group is terminated, for each associated fetch record whose request’s done flag or keepalive flag is unset, terminate the fetch record’s fetch.
2.5. 接続
~UAには `接続~pool@ が結付けられる。 `接続~pool$は、 0 個以上の `接続@ からなる。 各 `接続$は、組 ( `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 an origin (an origin) and credentials (a boolean).
`接続を得る@ ときは、所与の ( %生成元, %資格証 ) に対し,次を走らす: ◎ To obtain a connection, given an origin and credentials, run these steps:
- ~IF[ `接続~pool$内に,[ ( `origin^cN, `credentials^cN ) ~EQ ( %生成元, %資格証 ) ]を満たす`接続$はある ] ⇒ ~RET その`接続$ ◎ If connection pool contains a connection whose 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証明書は送信しないこと ◎ 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[ 接続の確立に成功しなかった(例: 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.
- `接続~pool$に,次のようにされた %接続 を追加する ⇒ ( `origin^cN, `credentials^cN ) ~SET ( %生成元, %資格証 ) ◎ Add connection to the connection pool with 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.
2.6. ~portの阻止-法
`要請$ %要請 の `~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.
- %~scheme ~LET %~url の`~scheme$url ◎ Let scheme be url’s scheme.
- %~port ~LET %~url の`~port$url ◎ Let port be url’s port.
- ~IF[ %~scheme ~EQ `ftp^l ]~AND[ %~port ~IN { 20, 21 } ] ⇒ ~RET `許容ed^i ◎ If scheme is "ftp" and port is 20 or 21, then return allowed.
- ~IF[ %~scheme ~IN `~network~scheme$ ]~AND[ %~port は`不良~port$である ] ⇒ ~RET `阻止ed^i ◎ Otherwise, if scheme is a network scheme and port is a bad port, then return blocked.
- ~RET `許容ed^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 | priv-rjs |
79 | finger |
87 | ttylink |
95 | supdup |
101 | hostriame |
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 | loc-srv / epmap |
139 | netbios |
143 | imap2 |
179 | bgp |
389 | ldap |
427 | afp (alternate) |
465 | smtp (alternate) |
512 | print / exec |
513 | login |
514 | shell |
515 | printer |
526 | tempo |
530 | courier |
531 | chat |
532 | netnews |
540 | uucp |
548 | afp |
556 | remotefs |
563 | nntp+ssl |
587 | smtp (outgoing) |
601 | syslog-conn |
636 | ldap+ssl |
993 | ldap+ssl |
995 | pop3+ssl |
2049 | nfs |
3659 | apple-sasl |
4045 | lockd |
6000 | x11 |
6665 | irc (alternate) |
6666 | irc (alternate) |
6667 | irc (default) |
6668 | irc (alternate) |
6669 | irc (alternate) |
6697 | irc+tls |
2.7. %要請 に対する %内部~応答 は,~MIME型に因り阻止されるべきか?
次の手続きを走らす: ◎ Run these steps:
-
~IF[ %要請 の`行先$rqは`~scriptに類する$ ]:
- %~MIME型 ~LET `~MIME型を抽出する$( %応答 の`~header~list$rs )
- ~IF[[ %~MIME型 の頭部は[ `audio/^bl, `image/^bl, `video/^bl ]のいずれかに合致する ]~OR[ %~MIME型 ~EQ `text/csv^bl ]] ⇒ ~RET `阻止ed^i:
- ~RET `許容ed^i ◎ Return allowed.
2.8. ~client~hint~list
注記: この節は HTTP Client Hints `CLIENT-HINTS$r に統合されることになる。 ◎ This section will be integrated into HTTP Client Hints. [CLIENT-HINTS]
`~client~hint~list@ は、どの~tokenも次を満たすような, ~client~hint~token の~listである ⇒ ~token ~IN { `DPR^bl, `Save-Data^bl, `Viewport-Width^bl, `Width^bl } ◎ A client hints list is a list of Client hint tokens, each of which is one of `DPR`, `Save-Data`, `Viewport-Width`, or `Width`.
2.9. ~stream
注記: この節は、~IDLなどの他の標準に統合されるかもしれない。 ◎ This section might be integrated into other standards, such as IDL.
2.9.1. ~ReadableStream
`~ReadableStream@ ~objは、`~dataの~stream$を表現する。 この節では、`~ReadableStream$~objたちに共通する演算を定義する。 `STREAMS$r ◎ A ReadableStream object represents a stream of data. In this section, we define common operations for ReadableStream objects. [STREAMS]
`~ReadableStream$~obj %~stream の中へ %~chunk を `~enqueue@RS するときは、次を走らす: ◎ To enqueue chunk into a ReadableStream object stream, run these steps:
- `ReadableStreamDefaultControllerEnqueue$A( %~stream.[[readableStreamController]], %~chunk ) を~callする ◎ Call ReadableStreamDefaultControllerEnqueue(stream.[[readableStreamController]], chunk).
`~ReadableStream$~obj %~stream を `~closeする@RS ときは、次を走らす: ◎ To close a ReadableStream object stream, run these steps:
- `ReadableStreamDefaultControllerClose$A( %~stream.[[readableStreamController]] ) を~callする ◎ Call ReadableStreamDefaultControllerClose(stream.[[readableStreamController]]).
`~ReadableStream$ ~obj %~stream を所与の %事由 で `~errorにする@RS ときは、次を走らす: ◎ To error a ReadableStream object stream with given reason, run these steps:
- `ReadableStreamDefaultControllerError$A( %~stream.[[readableStreamController]], %事由 ) を~callする ◎ Call ReadableStreamDefaultControllerError(stream.[[readableStreamController]]). reason).
`~ReadableStream~objを構築する@RS ときは、所与の ( %策, %~pull動作, %~cancel動作 ) (いずれも省略時は ε ) に対し,次を走らす: ◎ To construct a ReadableStream object with given strategy, pull action and cancel action, all of which are optional, run these steps:
- %init ~LET 新たな object ◎ Let init be a new object.
- ~IF[ %~pull動作 ~NEQ ε ] ⇒ %init[`pull^l] ~SET %~pull動作 を走らす~function ◎ Set init["pull"] to a function that runs pull if pull is given.
- ~IF[ %~cancel動作 ~NEQ ε ] ⇒ %init[`cancel^l] ~SET %~cancel動作 を走らす~function ◎ Set init["cancel"] to a function that runs cancel if cancel is given.
- %~stream ~LET ( %init, %策 ) を与える下で,[ `~ReadableStream$の初期~値 ]を構築子として~callした結果 ◎ Let stream be the result of calling the initial value of ReadableStream as constructor with init and strategy if given.
- ~RET %~stream ◎ Return stream.
`固定的~ReadableStream~objを構築する@RS ときは、所与の ( %~chunk列 ) に対し,次を走らす: ◎ To construct a fixed ReadableStream object with given chunks, run these steps:
- %~stream ~LET `~ReadableStream~objを構築する$RS() ◎ Let stream be the result of constructing a ReadableStream object.
- %~chunk列 内の ~EACH( %~chunk ) に対し ⇒ %~stream の中へ %~chunk を`~enqueue$RSする ◎ For each chunk in chunks, enqueue chunk into stream.
- %~stream を`~closeする$RS ◎ Close stream.
- ~RET %~stream ◎ Return stream.
`読取器を取得する@RS ときは、所与の ( `~ReadableStream$~obj %~stream ) に対し,次を走らす: ◎ To get a reader from a ReadableStream object stream, run these steps:
- %読取器 ~LET `AcquireReadableStreamDefaultReader$A( %~stream ) を~callした結果 ◎ Let reader be the result of calling AcquireReadableStreamDefaultReader(stream).
- ~RET %読取器 ◎ Return reader.
`~ReadableStream$ ~objから %読取器 で `~chunkを読取る@RS ときは、次を走らす:
- ~RET `ReadableStreamDefaultReaderRead$A( %読取器 ) を~callした結果
`~ReadableStream$~objから %読取器 で `すべての~byte列を読取る@RS ときは、次を走らす: ◎ To read all bytes from a ReadableStream object with reader, run these steps:
- %promise ~LET `新たな~promise$ ◎ Let promise be a new promise.
- %~byte列 ~LET 空の~byte列 ◎ Let bytes be an empty byte sequence.
-
`(A)^i:
%読取り ~LET `ReadableStreamDefaultReaderRead$A( %読取器 ) を~callした結果 ◎ Let read be the result of calling ReadableStreamDefaultReaderRead(reader).-
値 %値 による %読取り の`充足-時には$:
- ~IF[ %値 は~objである ]~AND[ %値 の `done^c ~prop ~EQ ~F ]~AND[ %値 の `value^c ~propは `Uint8Array$I ~objである ] ⇒# %~byte列 に `value^c ~propを付加する; 段 `(A)^i を再び走らす ◎ When read is fulfilled with an object whose done property is false and whose value property is a Uint8Array object, append the value property to bytes and run the above step again.
- ~ELIF[ %値 は~objである ]~AND[ %値 の `done^c ~prop ~EQ ~T ] ⇒ %~byte列 で %promise を`解決する$ ◎ When read is fulfilled with an object whose done property is true, resolve promise with bytes.
- ~ELSE ⇒ `TypeError^E で %promise を`却下する$ ◎ When read is fulfilled with a value that matches with neither of the above patterns, reject promise with a TypeError.
- ~errorによる %読取り の`却下-時には$ ⇒ その~errorで %promise を`却下する$ ◎ When read is rejected with an error, reject promise with that error.
-
- ~RET %promise ◎ Return promise.
`~ReadableStream$ ~obj %~stream を所与の %事由 で `取消す@RS ときは、 `ReadableStreamCancel$A( %~stream, %事由 ) を~callした結果を返す。 ◎ To cancel a ReadableStream object stream with reason, return the result of calling ReadableStreamCancel(stream, reason).
注記: 読取器への~accessは排他的になるので、読取りの実際の仕組みは, 【~script側からは】 観測し得ない。 実装は、自身に都合が良い より直接的な仕組みも利用できる。 ◎ Because the reader grants exclusive access, the actual mechanism of how to read cannot be observed. Implementations could use more direct mechanism if convenient.
`~ReadableStream$~obj %~stream を `二叉化@RS するときは、次を走らす: ◎ To tee a ReadableStream object stream, run these steps:
- ~RET `ReadableStreamTee$A( %~stream, ~T ) を~callした結果 ◎ Return the result of calling ReadableStreamTee(stream, true).
【 二叉化( ~tee ) — 元の~streamを同じに挙動する二つの~streamに分岐する( `tee コマンド^_, T 字路の “tee”)。 】
`空の~ReadableStream~obj@ は、次の結果を返す ⇒ `固定的~ReadableStream~objを構築する$RS( 空~list ) ◎ An empty ReadableStream object is the result of constructing a fixed ReadableStream object with an empty list.
注記: `空の~ReadableStream~obj$を構築する際には、例外は投出されない。 ◎ Constructing an empty ReadableStream object will not throw an exception.
`~ReadableStream$~obj %~stream は: ◎ ↓
- [ %~stream.[[state]] ~EQ `readable^l ]ならば, `読取可@RS ( `readable^en )という。 ◎ A ReadableStream object stream is said to be readable if stream.[[state]] is "readable".
- [ %~stream.[[state]] ~EQ `closed^l ]ならば, `~closeされた@RS ( `closed^en )という。 ◎ A ReadableStream object stream is said to be closed if stream.[[state]] is "closed".
- [ %~stream.[[state]] ~EQ `errored^l ]ならば, `~errorした@RS ( `errored^en )という。 ◎ A ReadableStream object stream is said to be errored if stream.[[state]] is "errored".
- [ `IsReadableStreamLocked$A( %~stream ) を~callした結果 ~EQ ~T ]ならば, `~lockされている@RS ( `locked^en )という。 ◎ A ReadableStream object stream is said to be locked if the result of calling IsReadableStreamLocked(stream) is true.
-
次の両~条件を満たすならば, `もっと~dataが必要@RS ( `need more data^en )という: ◎ A ReadableStream object stream is said to need more data if the following conditions hold:
- %~stream は`読取可$RSである。 ◎ stream is readable.
- `ReadableStreamDefaultControllerGetDesiredSize$A( %~stream.[[readableStreamController]] ) を~callした結果 ~GT 0 ◎ The result of calling ReadableStreamDefaultControllerGetDesiredSize(stream.[[readableStreamController]]). is positive.
- [ `IsReadableStreamDisturbed$A( %~stream ) を~callした結果 ~EQ ~T ]ならば, `妨げられている@RS ( `disturbed^en )という。 ◎ A ReadableStream object stream is said to be disturbed if the result of calling IsReadableStreamDisturbed(stream) is true.
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$のうち,[ %~CORS~flag が ~ON の下に行われるもの, および `要請$の`~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 CORS flag is set 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 / `%x6E.75.6C.6C^_ ; `null^bl, 大小区別
origin = `~scheme$url "://" `~host$url [ ":" `~port$url ]
注記: これは `ORIGIN$r による `Origin^h `~header$を置き換える。 【値に複数個の生成元を含められないようにされている。】 ◎ This supplants the `Origin` header. [ORIGIN]
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の仕組みが必要になる。 加えて,`資格証$を含む`要請$にも、~sensitiveになり得る~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$に関与しているとは限らない — `Origin$h ~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".
- 注記: `~CORS予行~要請$の際には,`要請$の`資格証~mode$rqは常に `omit^l であるが、後続の`~CORS要請$はそうでないこともある。 したがって、`~CORS予行~要請$に対する~HTTP応答の中でも,~supportの有無が指示される必要がある。 ◎ For a CORS-preflight request, request’s credentials mode is always "omit", 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 `~header$, および `Access-Control-Allow-Headers$h `~header$から供される情報が~cacheされ得る期間 【~UA側が~cacheを保持してもよい最長の期間】 を指示する。 ◎ Indicates how long 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応答に含ませては~MUST_NOT。 ~serverには、そのような~HTTP応答に `403$st `~status$を利用することが奨励される。 ◎ 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 = `%x74.72.75.65^_ ; `true^bl, 大小区別
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と資格証
[ `要請$の`資格証~mode$rq ~EQ `include^l ]のときには、`~fetching$の際に`資格証$を含ませること以外にも,`~CORS~protocol$の~~働きに影響0がある。 ◎ 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 へ向けた要請に対する種々の合法[ である/でない ]組合わせを~~説明する: ◎ 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を検証0することになる。 その値が[ `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 and any `Set-Cookie` response headers will end up being ignored.
3.2.7. ~CORS~protocol例外
仕様は、~CORS安全とされる~headerに対し,制限付きの例外を[ 安全とされていない `Content-Type$h ~header値 ]用に許容していた。 そのような例外は、[ ~web内容が誘発し得るが,~web内容が制御できるのは最小限の[ ~headerと本体 ]に限られるような要請 ]用に~~策定された。 したがって,~serverは、[[[ 次に挙げる[ 安全とされていない `Content-Type$h ~header値 ]を伴う,予行なしの要請 ]を誘発することが,非同一生成元の~web内容に許容される ]ものと予期するべきである: ◎ 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/report^bl `REPORTING$r
- `application/expect-ct-report+json^bl `EXPECT-CT$r
- `application/xss-auditor-report^bl
- `application/ocsp-request^bl `OCSP$r
仕様は、新たな例外を導入するのは避けるべきである — そうする場合、保安~上の帰結を注意深く考慮するべきである。 新たな例外は、 課題を~~提出して 提案できる。 ◎ 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. `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.
その`値$hd用の`~ABNF$は: ◎ Its value ABNF:
X-Content-Type-Options = "nosniff" ; 大小無視
3.3.1. %要請 に対する %応答 は, nosniff に因り阻止されるべきか?
次の手続きを走らす: ◎ Run these steps:
- %sniff ~LET %応答 の`~header~list$rs内の[ `X-Content-Type-Options$h を`名前に持つ~header$ ]からなる同順の~list ◎ ↓
- ~IF[ %sniff は空である ] ⇒ ~RET `許容ed^i ◎ If response’s header list does not contain `X-Content-Type-Options`, then return allowed.
- ~IF [ `~headerから値を抽出する$( %sniff 内の最初の`~header$ ) の結果 ~EQ `失敗^i ] ⇒ ~RET `許容ed^i ◎ Let nosniff be the result of extracting header values from the first header whose name is a byte-case-insensitive match for `X-Content-Type-Options` in response’s header list. ◎ If nosniff is failure, then return allowed.
- %~MIME型 ~LET `~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.
- ~IF[ %行先 は`~scriptに類する$ ]~AND[ %~MIME型 は(~parameterは無視して)`~JS~MIME型$でない ] ⇒ ~RET `阻止ed^i ◎ If destination is script-like and mimeType (ignoring parameters) is not a JavaScript MIME type, then return blocked.
- ~IF[ %行先 ~EQ `style^l ]~AND[ %~MIME型 は(~parameterは無視して) `text/css^bl でない ] ⇒ ~RET `阻止ed^i ◎ If destination is "style" and mimeType (ignoring parameters) is not `text/css`, then return blocked.
- ~RET `許容ed^i ◎ Return allowed.
注記: ここで考慮される`要請$の`行先$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.4. ~CORB
注記: ~CORBとも~~略称される,非同一生成元からの読取りの阻止-法( `Cross-Origin Read Blocking^en )は、疑わしい非同一生成元~資源~fetchを識別する~algoであり(例: `img^e 要素の内側にある~JSONを具現化しようと試みる様な~fetchは、どうやっても失敗することになる),それが~web頁に達する前に阻止する。 ~CORBは、~sensitiveな~dataを非同一生成元~web頁から離れた所に保って,それが漏洩する~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頁を妨害することなく,`~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 `許容ed^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 `許容ed^i ◎ If request’s current url’s scheme is not an HTTP(S) scheme, then return allowed.
- %~MIME型 ~LET `~MIME型を抽出する$( %応答 の`~header~list$rs ) ◎ Let mimeType be the result of extracting a MIME type from response’s header list.
- ~IF[ %応答 の`~status$rs ~EQ `206$st ]~AND[ %~MIME型 は(~parameterは無視して)`~CORBで保護される~MIME型$である ] ⇒ ~RET `阻止ed^i ◎ If response’s status is 206 and mimeType (ignoring parameters) is a CORB-protected MIME type, then return blocked.
- %nosniff ~LET `~headerから値を抽出する$( %応答 の`~header~list$rs内の[ `X-Content-Type-Options$h を`名前に持つ~header$ ]のうち 最初のもの ) ◎ Let nosniff be the result of extracting header values from the first header whose name is a byte-case-insensitive match for `X-Content-Type-Options` in response’s header list.
-
~IF[ %nosniff ~NEQ `失敗^i ]~AND[[ %~MIME型 は(~parameterは無視して)`~CORBで保護される~MIME型$である ]~OR[ %~MIME型 ~EQ `text/plain^bl ]] ⇒ ~RET `阻止ed^i ◎ If nosniff is not failure and mimeType (ignoring parameters) is a CORB-protected MIME type or text/plain, then return blocked.
注記: ~CORBが保護する `text/plain^bl 応答は、 `X-Content-Type-Options: nosniff^bl ~headerを伴うものに限られる。 あいにく,[ その~headerを伴わない, `~status$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 `許容ed^i ◎ Return allowed.
3.5. `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
= `%x73.61.6D.65.2D.6F.72.69.67.69.6E^_
/ `%x73.61.6D.65.2D.73.69.74.65^_
; `same-origin^bl / `same-site^bl, 大小区別
`非同一生成元~資源~施策~検査@ を遂行するときは、所与の ( %要請, %応答 ) に対し,次を走らす: ◎ To perform a cross-origin resource policy check, given a request and response, run these steps:
- ~IF[ %要請 の`~mode$rq ~NEQ `no-cors^l ] ⇒ ~RET `許容ed^i ◎ If request’s mode is not "no-cors", then return allowed.
-
~IF[ ( %要請 の`生成元$rq, %要請 の`現在の~url$rqの`生成元$url ) は、`同一生成元$である ] ⇒ ~RET `許容ed^i ◎ If request’s origin is same origin with request’s current url’s origin, then return allowed.
注記: `Cross-Origin-Resource-Policy$h ~headerを運ぶ~redirectは検査される一方で、そのような~headerを伴わない~redirectに対しては, %応答 はこの~algoに寄与しなくなる。 すなわち、 %要請 の`~tainted生成元~flag$rqは検査されない。 【?】 ◎ While redirects that carry a `Cross-Origin-Resource-Policy` header are checked, redirects without such a header resulting in response do not contribute to this algorithm. I.e., request’s tainted origin flag is not checked.
-
%施策 ~LET %応答 の`~header~list$rs内の `Cross-Origin-Resource-Policy$h に対する`結合-済みの値$hd ◎ Let policy be the combined value with `Cross-Origin-Resource-Policy` and response’s header list.
注記: これは、 `Cross-Origin-Resource-Policy: same-site, same-origin^bl に対しては,下にて `許容ed^i を返す結果になることを意味する — それが何かに合致することは決してないので。 `Cross-Origin-Resource-Policy$h ~headerが複数個ある場合も同じ効果になる。 ◎ This means that `Cross-Origin-Resource-Policy: same-site, same-origin` ends up as allowed below as it will never match anything. Two or more `Cross-Origin-Resource-Policy` headers will have the same effect.
- ~IF[ %施策 ~EQ `same-origin^bl ] ⇒ ~RET `阻止ed^i ◎ If policy is `same-origin`, then return blocked.
-
~IF[ 次のいずれかが満たされる ]: ◎ If the following are true
- ( %要請 の`生成元$rqの`~host$url, %要請 の`現在の~url$rqの`~host$url ) は`同じ~site$である ◎ request’s origin’s host is same site with request’s current url’s host
- [ %要請 の`生成元$rqの`~scheme$url ~EQ `https^l ]~OR[ %応答 の`~HTTPS状態$rs ~EQ `none^l ] ◎ request’s origin’s scheme is "https" or response’s HTTPS state is "none"
…ならば ⇒ ~RET `許容ed^i ◎ then return allowed.
注記: これは、[ `Cross-Origin-Resource-Policy: same-site^bl を伴う~HTTPS応答 ]が,保安的な~transportなしに~accessされることを防止する。 ◎ This prevents HTTPS responses with `Cross-Origin-Resource-Policy: same-site` from being accessed without secure transport.
- ~IF[ %施策 ~EQ `same-site^bl ] ⇒ ~RET `阻止ed^i ◎ If policy is `same-site`, then return blocked.
- ~RET `許容ed^i ◎ Return allowed.
4. ~fetching
注記: 下の~algoは、`~fetching$を定義する。 大雑把に言えば、それは`要請$を~~入力にとり,`応答$を出力する。 ◎ The algorithm below defines fetching. In broad strokes, it takes a request and outputs a response.
すなわち,[ `要請$の`同期~flag$rq ~EQ ~ON ]であれば`応答$を返し,そうでなければ,[ 以下において[ `応答を処理する$ / `応答の本体終端を処理する$ / `応答の~doneを処理する$ ]と記される,`応答$用の演算 ]を行うための`~fetch~taskを~queueする$。 ◎ That is, it either returns a response if request’s synchronous flag is set, or it queues tasks annotated process response, process response end-of-body, and process response done for the response.
~uploadを捕捉するため、[ `要請$の`同期~flag$rq ~EQ ~OFF ]の場合は、`要請$上で,[ 以下において[ `要請の本体を処理する$ / `要請の本体終端を処理する$ ]と記される演算 ]を行うための`~fetch~taskを~queueする$こともある。 ◎ To capture uploads, if request’s synchronous flag is unset, tasks annotated process request body and process request end-of-body for the request can be queued.
`要請$ %要請 を用いて `~fetch@ を遂行するときは、下に与える~algoを走らす: ◎ To perform a fetch using request, run the steps below.\
- 進行中の`~fetch$は, `終了され@ ることもある。 また,各 終了には `中止~flag^i が伴われ、指定されない限り ~OFF とする。 【同じ~fetchに対し,複数の終了が生じた場合、どの `中止~flag^i が優先される?】 ◎ An ongoing fetch can be terminated with flag aborted, which is unset unless otherwise specified.
- ~UAは、進行中の~fetchを `休止-@ するよう,請われることもある。 ~UAは、その休止~要請を受容しても無視しても~MAY。 休止された~fetchは、 `再開-@ できる。 ~UAは、[ 進行中の~fetchが,当の要請に対する[ ~HTTP~cache内の応答 ]を更新している場合 ]には,休止~要請を無視する~SHOULDである。 ◎ 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
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- ~IF[ %要請 の`~window$rq ~EQ `client^l ] ⇒ %要請 の`~window$rq ~SET [[ %要請 の`~client$rqの`大域~obj$enVは `Window$I ~objである ]ならば %要請 の`~client$rq / ~ELSE_ `no-window^l ] ◎ If request’s window is "client", set request’s window to request’s client, if request’s client’s global object is a Window object, and to "no-window" otherwise.
- ~IF[ %要請 の`生成元$rq ~EQ `client^l ] ⇒ %要請 の`生成元$rq ~SET %要請 の`~client$rqの`生成元$enV ◎ If request’s origin is "client", 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:
- %value ~LET `*/*^bl ◎ Let value be `*/*`.
-
~UAは, %value を次で与えられる値に設定する~SHOULDである: ◎ ↓
- %要請 は`~navi要請$であるならば ⇒ `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^bl ◎ If request is a navigation request, a user agent should set value to `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8`.
-
他の場合, %要請 の`行先$rqに応じて: ◎ Otherwise, a user agent should set value to the first matching statement, if any, switching on request’s destination:
- `image^l
- `image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5^bl
- `style^l
- `text/css,*/*;q=0.1^bl
- その他
- (何もせず、 %value はそのまま)
- %要請 の`~header~list$rqに`~headerを付加する$( `Accept$h / %value ) ◎ Append `Accept`/value to request’s header list.
- ~IF[ %要請 の`~header~list$rq内に[ `Accept-Language$h を`名前に持つ~header$ ]は無い ] ⇒ ~UAは、次を行う~SHOULDである ⇒ %要請 の`~header~list$rqに`~headerを付加する$( `Accept-Language$h / 適切な`値$hd ) ◎ If request’s header list does not contain `Accept-Language`, 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[ %要請 は`~navi要請$である ] ⇒ ~UAは、次を行う~SHOULDである ⇒ 下の表の ~EACH( 行を成す ( `名前$hd %~hint名, `値$hd %~hint値 ) ) に対し ⇒ ~IF[ %要請 の`~header~list$rq内に[ %~hint名 を`名前に持つ~header$ ]は無い ] ⇒ %要請 の`~header~list$rqに`~headerを付加する$( %~hint名 / %~hint値 )
◎ If request is a navigation request, a user agent should, for each header name (hintName) in the first column of the following table, if request’s header list does not contain hintName, then append hintName/the value given in the same row on the second column, to request’s header list.`名前$hd `値$hd `DPR^bl 相応しい `DPR$h 値 ◎ a suitable dpr value `Save-Data^bl 相応しい `Save-Data$h 値 ◎ a suitable save-data value `Viewport-Width^bl 相応しい `Viewport-Width$h 値 ◎ a suitable viewport-width value -
~IF[ %要請 は`下位資源~要請$である ]: ◎ If request is a subresource request, then:
-
%要請 の`~client~hint~list$rq内の ~EACH( %~hint名 ) に対し: ◎ For each hintName of request’s client hints list:
-
%値 ~LET %~hint名 に応じて,次で与えられる値: ◎ Let value be the first matching statement, switching on hintName:
- `DPR^bl ⇒ 相応しい `DPR$h 値 ◎ `DPR` • a suitable dpr value
- `Save-Data^bl ⇒ 相応しい `Save-Data$h 値 ◎ `Save-Data` • a suitable save-data value
- `Viewport-Width^bl ⇒ 相応しい `Viewport-Width$h 値 ◎ `Viewport-Width` • a suitable viewport-width value
- `Width^bl ⇒ 相応しい `Width$h 値 ◎ `Width` • a suitable width value
- ~UAは、次を行う~SHOULDである ⇒ %要請 の`~header~list$rqに`~headerを付加する$( %~hint名 / %値 ) ◎ A user agent should append hintName/value to request’s header list.
-
- %記録 ~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 終了-時の `中止~flag^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~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.
- ~RET %要請 を用いて`~main~fetch$を遂行した結果 ◎ Return the result of performing a main fetch using request.
4.1. ~main~fetch
( %~CORS~flag(省略時は ~OFF ), %再帰~flag(省略時は ~OFF ) ) が与えられた下で, 要請 %要請 を用いて `~main~fetch@ を遂行するときは、下の~algoを走らす。 ◎ To perform a main fetch using request, optionally with a CORS flag and recursive flag, run these steps:
注記: `~main~fetch$が再帰的に呼出されるときには, %再帰~flag は ~ON にされる。 %~CORS~flag は、~redirectを取扱うための内部状態管理に用いられる。 ◎ When main fetch is invoked recursively recursive flag is set. CORS flag is a bookkeeping detail for handling redirects.
- %応答 ~LET ~NULL ◎ Let response be null.
-
この段の中は、進行中の~fetchが`終了され$た`ときは中止する$: ◎ Run these steps, but abort when the ongoing fetch is terminated:
- ~IF[ %要請 の`局所~URLのみ~flag$ ~EQ ~ON ]~AND[ %要請 の`現在の~url$rqは`局所的$でない ] ⇒ %応答 ~SET `~network~error$ ◎ If request’s local-URLs-only flag is set and request’s current url is not local, set response to a network error.
- %要請 に対し ~CSP違反を報告する `CSP$r ◎ Execute Report Content Security Policy violations for request. [CSP]
- 適切になるなら %要請 を先天的に認証-済み~URLに昇格する `UPGRADE$r ◎ Upgrade request to a potentially secure URL, if appropriate. [UPGRADE]
-
~IF [ 次のいずれかの結果 ~EQ `阻止ed^i ]…:
- %要請 の`~fetchingは,不良~portに因り阻止されるべきか?$
- %要請 の~fetchingは,混在~内容として阻止されるべきか? `MIX$r
- %要請 の~fetchingは,~CSPにより阻止されるべきか? `CSP$r
…ならば ⇒ %応答 ~SET `~network~error$
◎ If should fetching request be blocked due to a bad port, should fetching request be blocked as mixed content, or should fetching request be blocked by Content Security Policy returns blocked, set response to a network error. [MIX] [CSP] - ~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 `no-referrer-when-downgrade^l ◎ If request’s referrer policy is the empty string, then set request’s referrer policy to "no-referrer-when-downgrade".
注記: ここでは `no-referrer-when-downgrade^l を利用する — それが、歴史的な既定なので。 ◎ We use "no-referrer-when-downgrade" because it is the historical default.
-
~IF[ %要請 の`~referrer$rq ~NEQ `no-referrer^l ] ⇒ %要請 の`~referrer$rq ~SET %要請 の`~referrerを決定-$した結果 `REFERRER$r ◎ If request’s referrer is not "no-referrer", set request’s referrer to the result of invoking determine request’s referrer. [REFERRER]
注記: `Referrer Policy^cite 仕様に言明されている様に、~UAは,末端利用者に対し, %要請 の`~referrer$rqを常に `no-referrer^l で上書きするような選択余地, または より~sensitiveでない情報を公開するような選択余地を与えることができる。 ◎ 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[ %要請 の`現在の~url$rqの`~scheme$url ~EQ `ftp^l ]~AND[ %要請 の`~client$rqの`作成時の~URL$enVの`~scheme$url ~NEQ `ftp^l ]~AND[ %要請 の`予約-済み~client$rqは[ ~NULL, または[ `環境$であって,その`~target閲覧文脈$enVは`入子の閲覧文脈$である ]]] ⇒ %応答 ~SET `~network~error$ ◎ If request’s current URL’s scheme is "ftp", request’s client’s creation URL’s scheme is not "ftp", and request’s reserved client is either null or an environment whose target browsing context is a nested browsing context, then set response to a network error.
-
~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 ◎ ↑
- 前~段が`中止されたときは$ ⇒ ~RET 終了-時の `中止~flag^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~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[ %要請 の`同期~flag$rq ~EQ ~OFF ]~AND[ %再帰~flag ~EQ ~OFF ] ⇒ ~RET — ただし、以降は`並列的$に走らす。 ◎ If request’s synchronous flag is unset and recursive flag is unset, 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:
- [ ( %要請 の`現在の~url$rqの`生成元$, %要請 の`生成元$rq ) は,`同一生成元$である ]~AND[ %~CORS~flag ~EQ ~OFF ] ◎ request’s current url’s origin is same origin with request’s origin and CORS flag is unset
- %要請 の`現在の~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$を遂行した結果 ◎ Return the result of performing a scheme fetch using request.
注記: ~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]
- %要請 の`~mode$rq ~EQ `same-origin^l ◎ request’s mode is "same-origin"
-
- ~RET `~network~error$ ◎ Return a network error.
- %要請 の`~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$を遂行した結果 ◎ Let noCorsResponse be the result of performing a scheme fetch using request.
- ~IF[ %~CORSなし要請 は`絞込み応答$である ]~OR[ `~CORB検査$( %要請, %~CORSなし要請 ) ~EQ `許容ed^i ] ⇒ ~RET %~CORSなし要請 ◎ If noCorsResponse is a filtered response or the CORB check with request and noCorsResponse returns allowed, then return noCorsResponse.
-
~RET 次のようにされた新たな`応答$ ⇒# `~status$rs ~SET %~CORSなし要請 の`~status$rs, `~HTTPS状態$rs ~SET %~CORSなし要請 の`~HTTPS状態$rs, `~CSP~list$rs ~SET %~CORSなし要請 の`~CSP~list$rs ◎ Return a new response whose status is noCorsResponse’s status, HTTPS state is noCorsResponse’s HTTPS state, 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.
- %要請 の`現在の~url$rqの`~scheme$url ~NIN `~HTTP_S~scheme$ ◎ request’s current url’s scheme is not an HTTP(S) scheme
-
- ~RET `~network~error$ ◎ Return a network error.
- %要請 の`~CORS予行~利用~flag$rq ~EQ ~ON ◎ request’s use-CORS-preflight flag is set
- [ %要請 の`非安全-要請~flag$rq ~EQ ~ON ]~AND[[ %要請 の`~method$rqは `~CORS安全な~method$でない ]~OR[ %要請 の`~header~list$rq内に`~CORS安全な要請~header$でない`~header$は在る ]] ◎ request’s unsafe-request flag is set and either request’s method is not a CORS-safelisted method or a header in request’s header list is not a CORS-safelisted request-header
-
- %要請 の`応答~tainting$rq ~SET `cors^l ◎ Set request’s response tainting to "cors".
- %~CORS予行~付き応答 ~LET ( %~CORS~flag ~SET ~ON, %~CORS予行~flag ~SET ~ON ) を与える下で, %要請 を用いて`~HTTP~fetch$を遂行した結果 ◎ Let corsWithPreflightResponse be the result of performing an HTTP fetch using request with CORS flag and CORS-preflight flag set.
- ~IF[ %~CORS予行~付き応答 は`~network~error$である ] ⇒ `~cache~entryを消去する$( %要請 ) ◎ If corsWithPreflightResponse is a network error, then clear cache entries using request.
- ~RET %~CORS予行~付き応答 ◎ Return corsWithPreflightResponse.
- ~OTHER ◎ Otherwise
-
- %要請 の`応答~tainting$rq ~SET `cors^l ◎ Set request’s response tainting to "cors".
- ~RET ( %~CORS~flag ~SET ~ON ) を与える下で, %要請 を用いて`~HTTP~fetch$を遂行した結果 ◎ Return the result of performing an HTTP fetch using request with CORS flag set.
- ~IF[ %再帰~flag ~EQ ~ON ] ⇒ ~RET %応答 ◎ If the recursive flag is set, 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名s ~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名s ~NIN { ~NULL, `失敗^i } ]: ◎ ↓
- ~IF[ %要請 の`資格証~mode$rq ~NEQ `include^l ]~AND[ `*^bl ~IN %~header名s ] ⇒ %応答 の`~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名s ◎ Otherwise, if headerNames is not null or failure, then set response’s CORS-exposed header-name list to headerNames.
注記: この時点でも, %~header名s のいずれかは `*^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の複製 ◎ If internalResponse’s url list is empty, then set it to a copy of request’s url list.
注記: `応答$の`~url~list$rsは、この時点では概して空である — ただし,~swから来た応答については、空になるのは `new Response()^m を通して作成されたものに限られる。 ◎ A response’s url list will typically be empty at this point, unless it came from a service worker, in which case it will only be empty if it was created through new Response().
- %内部~応答 の`~CSP~listを設定する$ `CSP$r ◎ Set internalResponse’s CSP list. [CSP]
-
~IF [ %応答 は`~network~error$でない ]~AND[ 次のいずれかの結果 ~EQ `阻止ed^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:
- %要請 に対する %内部~応答 は,混在~内容として阻止されるべきか? `MIX$r ◎ should internalResponse to request be blocked as mixed content [MIX]
- %要請 に対する %内部~応答 は,~CSPにより阻止されるべきか? `CSP$r ◎ should internalResponse to request be blocked by Content Security Policy [CSP]
- %要請 に対する %内部~応答 は,~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[ %内部~応答 の`~status$rs ~EQ `206$st ]~AND[ %内部~応答 の`範囲が要請された~flag$rs ~EQ ~ON ]~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 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[ %内部~応答 の`~status$rs は `~null本体~status$である ]] ⇒ %内部~応答 の`本体$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 [ %応答 は`~network~error$でない ]~AND[ %要請 の`完全性~metadata$rq ~NEQ 空~文字列 ]: ◎ If response is not a network error and request’s integrity metadata is not the empty string, then:
- `本体を待機する$( %応答 の`本体$rs ) ◎ Wait for response’s body.
- ~IF[[ %応答 の`本体$rsの`~stream$bdは`~errorした$RS ]でない ]~AND[ `応答は~metadata~listに合致するか?$( %応答, %要請 の`完全性~metadata$rq ) ~EQ ~F ] ⇒ ( %応答, %内部~応答 ) ~SET ( `~network~error$, `~network~error$ ) ◎ If response’s body’s stream has not errored, and response does not match request’s integrity metadata, set response and internalResponse to a network error. [SRI]
注記: これは %応答 上で演算する — この~algoは %内部~応答 を観測するように想定されていないので。 それを許容すると、攻撃者が~hashを神託機械†( `oracle^en )として利用できるようになる。 【† — 参考: cryptographic oracle, padding oracle attack, `ランダムオラクル^_ 】 ◎ This operates on response as this algorithm is not supposed to observe internalResponse. That would allow an attacker to use hashes as an oracle.
-
~IF[ %要請 の`同期~flag$rq ~EQ ~ON ]:
- `本体を待機する$( %内部~応答 の`本体$rs )
- ~RET %応答
注記: これは`~fetch$を終了させる。 ◎ This terminates fetch.
-
~IF[ %要請 の`現在の~url$rqの`~scheme$url ~IN `~HTTP_S~scheme$ ]: ◎ If request’s current url’s scheme is an HTTP(S) scheme, then:
- ~IF[ %要請 の`本体$rqは`~done$bdでない ] ⇒ `並列的$に,`本体を待機する$( %要請 の`本体$rq ) ◎ ↓
- %要請 に対する`~fetch要請~done~taskを~queueする$ ◎ If request’s body is done, queue a fetch-request-done task for request. ◎ Otherwise, in parallel, wait for request’s body, and then queue a fetch-request-done task for request.
- %要請 上で[ %応答 に対し`応答を処理する$ ]ための`~fetch~taskを~queueする$ ◎ Queue a fetch task on request to process response for response.
- `本体を待機する$( %内部~応答 の`本体$rs ) ◎ Wait for internalResponse’s body.
- %要請 上で[ %応答 に対し`応答の本体終端を処理する$ ]ための`~fetch~taskを~queueする$ ◎ Queue a fetch task on request to process response end-of-body for response.
-
次のいずれかが生じるまで待機する ⇒# %内部~応答 の`~trailer$rsがすべて得られた† / 進行中の~fetchは`終了され$た
`HTTP$r 4.1.2 節 を見よ。 【†~trailerが無い場合も、おそらく “空の~trailerが在る” と見做す(すなわち、本体が完全に得られるまで)。】
◎ Wait for either internalResponse’s trailer, if any, or for the ongoing fetch to terminate. See section 4.1.2 of [HTTP]. - ~IF[ 進行中の~fetchは`終了され$た ] ⇒ %内部~応答 の`~trailerは失敗した~flag$rs ~SET ~ON ◎ If the ongoing fetch is terminated, then set internalResponse’s trailer failed flag.
- %要請 の`~done~flag$rq ~SET ~ON ◎ Set request’s done flag.
- %要請 上で[ %応答 に対し`応答の~doneを処理する$ ]ための`~fetch~taskを~queueする$ ◎ Queue a fetch task on request to process response done for response.
4.2. ~scheme~fetch
要請 %要請 を用いて `~scheme~fetch@ を遂行するときは、 %要請 の`現在の~url$rq の`~scheme$urlに応じて,次の中から 対応する手続きを走らす: ◎ To perform a scheme fetch using request, switch on request’s current url’s scheme, and run the associated steps:
- `about^l
-
- %~url ~LET %要請 の`現在の~url$rq ◎ ↓
-
~IF[ %~url の`~cannot-be-a-base-URL~flag$url ~EQ ~ON ]~AND[ %~url の`~path$urlは 単独の文字列 `blank^l からなる ]:
- %応答 ~LET 次のように設定された,新たな`応答$ ⇒# `~status~message$rs ~SET `OK^bl, `~header~list$rs ~SET « `新たな~header$( `Content-Type$h / `text/html;charset=utf-8^bl ) », `本体$rs ~SET 空~byte列
- ~IF[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ %応答 の`~HTTPS状態$rs ~SET %要請 の`~client$rqの`~HTTPS状態$enV
- ~RET %応答
- ~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の`~obj$url ◎ Let blob be request’s current url’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 次のように設定された,新たな`応答$ ⇒ `~status~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.
- ~IF[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ %応答 の`~HTTPS状態$rs ~SET %要請 の`~client$rqの`~HTTPS状態$enV ◎ Set response’s HTTPS state to request’s client’s HTTPS state if request’s client is non-null.
- %応答 の`本体$rs ~SET %blob に対し`読取り演算$xを遂行した結果 ◎ Set response’s body to the result of performing the read operation on blob.
- ~RET %応答 ◎ Return response.
- 前~段が`中止されたときは$ ⇒ ~RET 終了-時の `中止~flag^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~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.
- %応答 ~LET 次のように設定された,新たな`応答$ ⇒# `~status~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, body is dataURLStruct’s body,\
- ~IF[ %要請 の`~client$rq ~NEQ ~NULL ] ⇒ %応答 の`~HTTPS状態$rs ~SET %要請 の`~client$rqの`~HTTPS状態$enV ◎ and HTTPS state is request’s client’s HTTPS state if request’s client is non-null.
- ~RET %応答 ◎ ↑
- `file^l
- `ftp^l
- 現時点では、[ file / ftp ]`~URL$については、あいにく~~未解決( `exercise for the reader^en )である。 ◎ For now, unfortunate as it is, file and ftp URLs are left as an exercise for the reader.
- 疑わしい場合は`~network~error$を返すこと。 ◎ When in doubt, return a network error.
- `filesystem^l
-
~IF[ %要請 の`~sandboxed-storage-area-URLs~flag$ ~EQ ~ON ] ⇒ ~RET `~network~error$ ◎ If request’s sandboxed-storage-area-URLs flag is set, return a network error.
~ELSE ⇒ 課題: … この~schemeは、依然,定義される必要がある。 ◎ Otherwise, … this scheme still needs to be defined.
- `~HTTP_S~scheme$
- ~RET %要請 を用いて`~HTTP~fetch$を遂行した結果 ◎ Return the result of performing an HTTP fetch using request.
- ~OTHER ◎ Otherwise
- ~RET `~network~error$ ◎ Return a network error.
4.3. ~HTTP~fetch
( %~CORS~flag(省略時は ~OFF ), %~CORS予行~flag(省略時は ~OFF ) ) が与えられた下で, %要請 を用いて `~HTTP~fetch@ を遂行するときは、次を走らす: ◎ To perform an HTTP fetch using request with an optional CORS flag and CORS-preflight flag, run these steps:
注記: %~CORS~flag は、ここでも内部状態管理に用いられる。 %~CORS予行~flag も同様であり、`~CORS予行~要請$が必要になることを指示する。 ◎ CORS flag is still a bookkeeping detail. As is CORS-preflight flag; it indicates a CORS-preflight request is needed.
- %応答 ~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:
- %応答 ~SET %要請 に対し ~fetchを取扱った 結果 `HTML$r `SW$r ◎ Set response to the result of invoking handle fetch for request. [HTML] [SW]
-
~IF[ %応答 ~NEQ ~NULL ]: ◎ If response is not null, then:
- `要請~用の本体を伝送する$( %要請 ) ◎ Transmit body for request.
- %実-応答 ~SET [ %応答 は`絞込み応答$でないならば %応答 / ~ELSE_ %応答 の`内部~応答$ ] ◎ Set actualResponse to response, if response is not a filtered response, and to response’s internal response otherwise.
-
~IF[ 次のいずれかの条件が満たされる ] ⇒ ~RET `~network~error$: ◎ If one of the following conditions is true, then return a network error:
- %応答 の`種別$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.
-
~IF[ %応答 ~EQ ~NULL ]: ◎ If response is null, then:
-
~IF[ %~CORS予行~flag ~EQ ~ON ]~AND[ 次のいずれかが満たされる ]…: ◎ If the CORS-preflight flag is set and one of these conditions is true:
-
[ `~methodも合致している~cache~entry$( %要請, %要請 の`~method$rq ) ~NEQ ε ]~AND[ %要請 は、次のいずれかを満たす ]:
- `~method$rqは `~CORS安全な~method$でない
- `~CORS予行~利用~flag$rq ~EQ ~ON
-
%要請 の`~header~list$rq内に,次の両者とも満たす`~header$は在る:
- `~header名も合致している~cache~entry$( %要請, ~headerの`名前$hd ) ~NEQ ε
- `~CORS安全な要請~header$でない
…ならば: ◎ Then:
- %予行~応答 ~LET %要請 を用いて`~CORS予行~fetch$を遂行した結果 ◎ Let preflightResponse be the result of performing a CORS-preflight fetch using 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 ( %~CORS~flag ) をそのまま与える下で, %要請 を用いて`~HTTP~network-or-cache~fetch$を遂行した結果 ◎ Set response and actualResponse to the result of performing an HTTP-network-or-cache fetch using request with CORS flag if set.
- %応答 ~SET %実-応答 ◎ ↑
-
~IF[ %~CORS~flag ~EQ ~ON ]~AND[ `~CORS検査$( %要請, %応答 ) ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If CORS flag is set and a CORS check for request and response returns failure, then return a network error.
注記: `~CORS検査$は、[ `~status$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[ %実-応答 の`~status$rsは`~redirect~status$である ]: ◎ If actualResponse’s status is a redirect status, then:
-
~IF[ %実-応答 の`~status$rs ~NEQ `303$st ]~AND[ %要請 の`本体$rq ~NEQ ~NULL ]~AND[ `接続$は~HTTP2を利用している ] ⇒ ~UAは `RST_STREAM^c ~frameを伝送して~MAY — また,そうすることが奨励される。 ◎ 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 は特別な~statusに帰するとみなされ,除外される。 ◎ 303 is excluded as certain communities ascribe special status to it.
- %所在 ~LET `~header~listから値を抽出する$( %実-応答 の`~header~list$rs, `Location$h ) ◎ Let location be the result of extracting header list values given `Location` and actualResponse’s header list.
- ~IF[ %所在 は`値$hdである ] ⇒ %所在 ~SET `~URL構文解析する$( %所在, %実-応答 の`~url$rs ) ◎ If location is a value, then set location to the result of parsing location with actualResponse’s url.
- %実-応答 の`所在~URL$rs ~SET %所在 ◎ Set actualResponse’s location URL to location.
-
%要請 の`~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 ( %~CORS~flag ) をそのまま与える下で, ( %要請, %応答 ) を用いて`~HTTP~redirect~fetch$を遂行した結果 ◎ Set response to the result of performing HTTP-redirect fetch using request and response with CORS flag if set.
-
- ~RET %応答 注記: 手続きはここで終わるが,その後も概して、 %実-応答 の`本体$rsの`~stream$bdには,~byte列が~enqueueされ続ける。 ◎ Return response. Typically actualResponse’s body’s stream is still being enqueued to after returning.
4.4. ~HTTP~redirect~fetch
注記: この~algoは、上述の`~HTTP~fetch$に加えて,~HTMLの~navigate~algoからも利用される。 `HTML$r ◎ This algorithm is used by HTML’s navigate algorithm in addition to HTTP fetch above. [HTML]
%~CORS~flag(省略時は ~OFF )が与えられた下で, ( %要請, %応答 ) を用いて `~HTTP~redirect~fetch@ を遂行するときは、次を走らす: ◎ To perform an HTTP-redirect fetch using request and response, with an optional CORS flag, run these steps:
- %実-応答 ~LET [ %応答 は`絞込み応答$でないならば %応答 / ~ELSE_ %応答 の`内部~応答$ ] ◎ Let actualResponse be response, if response is not a filtered response, and response’s internal response otherwise.
- %所在 ~LET %実-応答 の`所在~URL$rs ◎ ↓
- ~IF[ %所在 ~EQ ~NULL ] ⇒ ~RET %応答 ◎ If actualResponse’s location URL is null, then return response.
- ~IF[ %所在 ~EQ `失敗^i ] ⇒ ~RET `~network~error$ ◎ If actualResponse’s location URL is failure, then return a network error.
- ~IF[ %所在 の`~scheme$url ~NIN `~HTTP_S~scheme$ ] ⇒ ~RET `~network~error$ ◎ If actualResponse’s location URL’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[ %所在 は`資格証を含む$url ]~AND[[ %要請 の`~tainted生成元~flag$rq ~EQ ~ON ]~OR[ ( %要請 の`生成元$rq, %所在 の`生成元$url ) は,`同一生成元$でない ]] ⇒ ~RET `~network~error$ ◎ If request’s mode is "cors", actualResponse’s location URL includes credentials, and either request’s tainted origin flag is set or request’s origin is not same origin with actualResponse’s location URL’s origin, then return a network error.
-
~IF[ %~CORS~flag ~EQ ~ON ]~AND[ %所在 は`資格証を含む$url ] ⇒ ~RET `~network~error$ ◎ If CORS flag is set and actualResponse’s location URL includes credentials, then return a network error.
注記: これは、非同一生成元~資源による同一生成元~URLへの~redirectを捕える。 ◎ This catches a cross-origin resource redirecting to a same-origin URL.
- ~IF[ %実-応答 の`~status$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[ ( %所在 の`生成元$url, %要請 の`現在の~url$rqの`生成元$rq ) は,`同一生成元$でない ]~AND[ ( %要請 の`生成元$url, %要請 の`現在の~url$rqの`生成元$rq ) は,`同一生成元$でない ] ⇒ %要請 の`~tainted生成元~flag$rq ~SET ~ON ◎ If actualResponse’s location URL’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[[ %実-応答 の`~status$rs ~IN { `301$st, `302$st } ]~AND[ %要請 の`~method$rq ~EQ `POST$hm ]]~OR[ %実-応答 の`~status$rs ~EQ `303$st ] ⇒# %要請 の`~method$rq ~SET `GET$hm; %要請 の`本体$rq ~SET ~NULL ◎ If either actualResponse’s status is 301 or 302 and request’s method is `POST`, or actualResponse’s status is 303, set request’s method to `GET` and request’s body to null.
-
~IF[ %要請 の`本体$rq ~NEQ ~NULL ] ⇒ %要請 の`本体$rq ~SET [ `本体と内容~型を抽出する$( %要請 の`本体$rqの`~source$bd ) ]の結果の`本体$ ◎ If request’s body is non-null, then set request’s body to the first part of extracting request’s body’s source.
注記: `~source$bdが ~NULL でないことは、すでに検査~済み。 また、`本体と内容~型を抽出する$ときに例外が投出されることはない — 前に同じ`~source$bdで~callされているので。 ◎ request’s body’s source’s nullity has already been checked. The extracting operation cannot throw as it was called for the same source before.
- %要請 の`~url~list$rqに %所在 を付加する ◎ Append actualResponse’s location URL to request’s url list.
- `~referrer施策を設定する$( %要請, %実-応答 ) `REFERRER$r ◎ Invoke set request’s referrer policy on redirect on request and actualResponse. [REFERRER]
-
~RET 次を与える下で, %要請 を用いて`~main~fetch$を遂行した結果: ◎ Return the result of performing a main fetch using request with
- %~CORS~flag ~SET %~CORS~flag ◎ CORS flag if set and
-
%再帰~flag ~SET [ %要請 の`~redirect~mode$rq ~NEQ `manual^l ならば ~ON / ~ELSE_ ~OFF ] ◎ recursive flag set if request’s redirect mode is not "manual".
注記: `manual^l になるのは、~HTMLの~navigate~algoから直に呼出されたときに限られる。 ◎ It can only be "manual" when invoked directly from HTML’s navigate algorithm.
注記: `応答~tainting$rqが正しくなるように`~main~fetch$を呼出す必要がある。 ◎ This has to invoke main fetch to get response tainting correct.
4.5. ~HTTP~network-or-cache~fetch
( %~CORS~flag(省略時は ~OFF ), %認証~fetch~flag(省略時は ~OFF ) ) が与えられた下で, %要請 を用いて `~HTTP~network-or-cache~fetch@ を遂行するときは、次を走らす: ◎ To perform an HTTP-network-or-cache fetch using request with an optional CORS flag and authentication-fetch flag, run these steps:
注記: %~CORS~flag, %認証~fetch~flag は、ここでも内部状態管理に用いられる。 ◎ CORS flag is still a bookkeeping detail. As is authentication-fetch flag.
注記: `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. [HTTP-RANGE] However, this is not widely supported by browser caches.
- %~http要請 ~LET ~NULL ◎ Let httpRequest be null.
- %応答 ~LET ~NULL ◎ Let response be null.
- %格納-済み応答 ~LET ~NULL ◎ Let storedResponse be null.
- %再検証~flag ~LET ~OFF ◎ 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要請 ~SET %要請 ◎ If request’s window is "no-window" and request’s redirect mode is "error", then set httpRequest to request.
-
~ELSE: ◎ Otherwise:
- %~http要請 ~SET %要請 の`本体$rqを除いた部分の複製 ◎ Set httpRequest to a copy of request except for its body.
- %本体 ~LET %要請 の`本体$rq ◎ Let body be request’s body.
- %~http要請 の`本体$rq ~SET %本体 ◎ Set httpRequest’s body to body.
- ~IF[ %本体 ~NEQ ~NULL ] ⇒ %要請 の`本体$rq ~SET 次のようにされた新たな`本体$ ⇒# `~stream$bd ~SET ~NULL; `~source$bd ~SET %本体 の`~source$bd ◎ If body is non-null, then set request’s body to a new body whose stream is null and whose source is body’s source.
注記: %要請 は複製される — ここでの %~http要請 は、 %要請 に影響させずに, ~headerを追加できたり, その`本体$rqを読取れるようにする必要があるので。 すなわち、 %要請 は[ ~redirect / 認証 / ~proxy認証 ]にて再利用できる。 また,~memory消費を抑制するため、~cloneせずに複製する。 [ %要請 の`本体$rqの`~source$bd ~EQ ~NULL ]の事例で[ ~redirect / 認証 ]が生じた場合、~fetchは失敗することになる。 ◎ request is copied as httpRequest here as we need to be able to add headers to httpRequest and read its body without affecting request. Namely, request can be reused with redirects, authentication, and proxy authentication. We copy rather than clone in order to reduce memory consumption. In case request’s body’s source is null, redirects and authentication will end up failing the fetch.
-
%資格証~flag ~LET [ 次のいずれかが満たされるならば ~ON / ~ELSE_ ~OFF ]: ◎ Let credentials flag be set if one of
- %要請 の`資格証~mode$rq ~EQ `include^l ◎ request’s credentials mode is "include"
- [ %要請 の`資格証~mode$rq ~EQ `same-origin^l ]~AND[ `応答~tainting$rq ~EQ `basic^l ] ◎ request’s credentials mode is "same-origin" and request’s response tainting is "basic"
◎ is true, and unset otherwise.
- %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~flag$rq ~EQ ~ON ]: ◎ If contentLengthValue is non-null and httpRequest’s keepalive flag is set, 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~flag$rq ~EQ ~ON ]~AND[ `~done~flag$rq ~EQ ~OFF ] ◎ Let inflightRecords be the set of fetch records in group whose request has its keepalive flag set and done flag 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.
- ~IF[ %~CORS~flag ~EQ ~ON ]~OR[ %~http要請 の`~method$rq ~NIN { `GET$hm, `HEAD$hm } ]~OR[ %~http要請 の`~mode$rq ~EQ `websocket^l ] ⇒ %~http要請 の`~header~list$rqに`~headerを付加する$( `Origin$h / `要請の生成元を直列化する$( %~http要請 ) ) ◎ If the CORS flag is set, httpRequest’s method is neither `GET` nor `HEAD`, or httpRequest’s mode is "websocket", then append `Origin`/the result of serializing a request origin with httpRequest, to httpRequest’s header list.
- ~IF[ %~http要請 の`~header~list$rq内に[ `User-Agent$h を`名前に持つ~header$ ]は無い ] ⇒ ~UAは、次を行う~SHOULDである ⇒ %~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要請 の`~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" 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$は含ませては~MUST_NOT ⇒ `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[ %資格証~flag ~EQ ~ON ]: ◎ If credentials flag is set, then:-
~IF[ ~UAは %~http要請 用の~cookieを阻止するように環境設定されていない( `COOKIES$r の 7 節 を見よ) ]: ◎ 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 ) を与える下で "cookie-string" ~algo( `COOKIES$r の 5.4 節 )を走らせた結果 ◎ 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 ~OFF ]~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~flag ~EQ ~ON ] ⇒ %権限付与~値 ~SET %~http要請 の`現在の~url$rqを `Authorization$h 値に変換- した結果 ◎ Otherwise, if httpRequest’s current url does include credentials and authentication-fetch flag is set, 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.
-
`(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 ◎ Set storedResponse to the result of selecting a response from the HTTP cache, possibly needing validation, as per the "Constructing Responses from Caches" chapter of HTTP Caching [HTTP-CACHING], if any.
注記: ~HTTPにより義務付けられているように、これには,依然として `Vary$h `~header$も織り込まれる。 ◎ As mandated by HTTP, this still takes the `Vary` header into account.
- ~IF[ %格納-済み応答 には検証が要求される(すなわち,新鮮でない) ] ⇒ %再検証~flag ~SET ~ON ◎ ↑If storedResponse is non-null, then: ◎ If storedResponse requires validation (i.e., it is not fresh), then set the revalidatingFlag.
-
~IF[ %再検証~flag ~EQ ~ON ]~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^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~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.
- %~forward応答 ~LET %資格証~flag をそのまま与える下で, %~http要請 を用いて`~HTTP~network~fetch$を発行した結果 ◎ Let forwardResponse be the result of making an HTTP-network fetch using httpRequest with credentials flag if set.
- ~IF[ %~http要請 の`~method$rqは 安全でない ]~AND[ %~forward応答 の`~status$rs ~IN { `200^st 〜 `399^st } ] ⇒# `HTTP Caching^cite による 無効化にしたがって,~HTTP~cache内の適切な格納-済み応答たちを無効化する `HTTP-CACHING$r; %格納-済み応答 ~SET ~NULL ◎ If httpRequest’s method is unsafe and forwardResponse’s status is in the range 200 to 399, inclusive, invalidate appropriate stored responses in the HTTP cache, as per the "Invalidation" chapter of HTTP Caching, and set storedResponse to null. [HTTP-CACHING]
-
~IF[ %再検証~flag ~EQ ~ON ]~AND[ %~forward応答 の`~status$rs ~EQ `304$st ]: ◎ If the revalidatingFlag is set and forwardResponse’s status is 304, then:
-
`HTTP Caching^cite による 検証にあたっての,格納-済み応答の新鮮化-法 にしたがって, %~forward応答 の`~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 %~forward応答 ◎ Set response to forwardResponse.
-
`HTTP Caching^cite による ~cache内への応答の格納-法 にしたがって,~HTTP~cache内に[ %~http要請, %~forward応答 ]を格納する `HTTP-CACHING$r ◎ Store httpRequest and forwardResponse in the HTTP cache, as per the "Storing Responses in Caches" chapter of HTTP Caching. [HTTP-CACHING]
注記: %~forward応答 が`~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".
- ~IF[ %~http要請 の`~header~list$rq内に[ `Range$h を`名前に持つ~header$ ]は在る ] ⇒ %応答 の`範囲が要請された~flag$rs ~SET ~ON ◎ If httpRequest’s header list contains `Range`, then set response’s range-requested flag.
- ~IF[ %~CORS~flag ~EQ ~OFF ]~AND[ `非同一生成元~資源~施策~検査$( %要請, %応答 ) ~EQ `阻止ed^i ] ⇒ ~RET `~network~error$ ◎ If the CORS flag is unset and the cross-origin resource policy check with request and response returns blocked, then return a network error.
-
~IF[ %応答 の`~status$rs ~EQ `401$st 【Unauthorized】 ]~AND[ %資格証~flag ~EQ ~ON ]~AND[ %要請 の`~window$rqは`環境~設定群~obj$である ]: ◎ If response’s status is 401, CORS flag is unset, credentials flag is set, 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 part of extracting request’s body’s source.
注記: `本体と内容~型を抽出する$ときに例外が投出されることはない — 前に同じ`~source$bdで~callされているので。 ◎ The extracting operation cannot throw as it was called for the same source before.
-
~IF[ %要請 の`資格証利用URL~flag$rq ~EQ ~OFF ]~OR[ %認証~fetch~flag ~EQ ~ON ]: ◎ If request’s use-URL-credentials flag is unset or authentication-fetch flag is set, then:
- ~IF[ 進行中の~fetchは`終了され$た ] ⇒ ~RET 終了-時の `中止~flag^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~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 ( %認証~fetch~flag ~SET ~ON ) を与える下で, %要請 を用いて`~HTTP~network-or-cache~fetch$を遂行した結果 ◎ Set response to the result of performing an HTTP-network-or-cache fetch using request with authentication-fetch flag set.
-
~IF[ %応答 の`~status$rs ~EQ `407$st 【Proxy Authentication Required】 ]: ◎ 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^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~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 ( %~CORS~flag ) をそのまま与える下で, %要請 を用いて`~HTTP~network-or-cache~fetch$を遂行した結果 ◎ Set response to the result of performing an HTTP-network-or-cache fetch using request with CORS flag if set.
- ~IF[ %認証~fetch~flag ~EQ ~ON ] ⇒ [ %要請, および所与の~realm ]用の`認証~entry$を作成する ◎ If authentication-fetch flag is set, 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.6. ~HTTP~network~fetch
( %資格証~flag(省略時は ~OFF ) ) が与えられた下で, %要請 を用いて `~HTTP~network~fetch@ を遂行するときは、次を走らす: ◎ To perform an HTTP-network fetch using request with an optional credentials flag, run these steps:
- %資格証 ~LET [ %資格証~flag ~EQ ~ON ならば ~T / ~ELSE_ ~F ] ◎ Let credentials be true if credentials flag is set, and false otherwise.
- %応答 ~LET ~NULL ◎ Let response be null.
-
%接続 ~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_ ⇒ `接続を得る$( %要請 の`現在の~url$rqの`生成元$url, %資格証 ) ◎ Otherwise • Let connection be the result of obtaining a connection, given request’s current url’s origin and credentials.
-
この段の中は、進行中の~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.
-
`応答$のうち,[ `~status$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.
%要請 の`~header~list$rqが ( `Transfer-Encoding$h / `chunked^bl ) を包含する場合は ⇒ ~IF[ %応答 は HTTP/1.0 以下の~versionを介して転送されている ] ⇒ ~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.
~IF[ %応答 は~HTTPS越しに検索取得された ] ⇒ その`~HTTPS状態$rs ~SET [ `deprecated^l または `modern^l ] `TLS$r ◎ If response was retrieved over HTTPS, set its HTTPS state to either "deprecated" or "modern". [TLS]
注記: ここでの正確な決定は、現時点では~UAに委ねられる。 ~UAには、保安が強固な~TLS接続についてのみ成功し,他の場合は`~network~error$を返すことが、強く奨励される。 `deprecated^l 状態~値の利用は一時的とされるべきであり,最後の~~手段の類の~optionである。 ◎ The exact determination here is up to user agents for the time being. User agents are strongly encouraged to only succeed HTTPS connections with strong security properties and return network errors otherwise. Using the "deprecated" state value ought to be a temporary and last resort kind of option.
`要請~用の本体を伝送する$( %要請 ) ◎ Transmit body for request.
-
前~段が`中止されたときは$: ◎ 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^i に応じて ⇒# ~ON ならば `中止~network~error$ / ~OFF ならば `~network~error$ ◎ If aborted is set, then return an aborted network error. ◎ Return a network error.
-
%策 ~LET ~obj — ~UAは、どのような~objを選んでも~MAY。 ◎ Let strategy be an object. The user agent may choose any object.
注記: %策 は、[[ 下で構築される %~stream ]の~queuing策 ]を制御するために利用される。 ◎ strategy is used to control the queuing strategy of stream constructed below.
- %~pull ~LET 進行中の~fetchが`休止-$しているならば,それを`再開-$する動作 ◎ Let pull be an action that resumes the ongoing fetch if it is suspended.
- %~cancel ~LET 次を走らす動作 ⇒ 進行中の~fetchを`終了させる$( `中止~flag^i ~SET ~ON ) ◎ Let cancel be an action that terminates the ongoing fetch with the aborted flag set.
-
%~stream ~LET `~ReadableStream~objを構築する$RS( %策, %~pull, %~cancel ) ◎ Let stream be the result of constructing a ReadableStream object with strategy, pull and cancel.
注記: この構築~演算からは、例外は投出されない。 ◎ This construction operation will not throw an exception.
-
この段の中は、進行中の~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[ %応答 には~payload本体~長さ %L がある ] ⇒ %応答 の`本体$rsの`総~byte数$bd ~SET %L ◎ If response has a payload body length, then set response’s body’s total bytes to that payload body length.
-
次の下位手続きを走らす:
- %~list ~LET %応答 の`~header~list$rs
- %符号法s ~LET `~header~listから値を抽出する$( %~list, `Content-Encoding$h )
- %型 ~LET `~header~listから値を抽出する$( %~list, `Content-Type$h )
-
~IF [ 次のいずれかが満たされる ]:
- [ %符号法s は `gzip^bl のみからなる ]~AND[ %型 ~IN { `application/gzip^bl, `application/x-gunzip^bl, `application/x-gzip^bl } ]
- [ %符号法s は `compress^bl のみからなる ]~AND[ %型 ~IN { `application/compress^bl, `application/x-compress^bl } ]
…ならば ⇒ %~list から`~headerを削除する$( `Content-Encoding$h )
注記: この段は、壊れた Apache 環境設定に対処する。 ~HTTPにて定義されるのが理想だが。 ◎ This deals with broken Apache configurations. Ideally HTTP would define this.
課題: この quirk (過去互換)は,除去できるか? ~~詳細は Gecko bug 1030660 に。 ◎ Gecko bug 1030660 looks into whether this quirk can be removed.
- ~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", update response in the HTTP cache for request.
-
~IF[ %資格証~flag ~EQ ~ON ]~AND[ ~UAは %要請 用の~cookieを阻止するように環境設定されていない( `COOKIES$r の 7 節 を見よ) ] ⇒ %応答 の`~header~list$rs内の ~EACH ( `Set-Cookie$h を`名前に持つ~header$ %~header ) に対し ⇒ ( %~header の`値$hd, %要請 の`現在の~url$rq ) を与える下で, "set-cookie-string" 構文解析~algo( `COOKIES$r の 5.2 節 を見よ)を走らす ◎ If credentials flag is set 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^i ~EQ ~ON ] ⇒ %応答 の`中止~flag$rs ~SET ~ON ◎ 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[ %応答 の~message本体に対し 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.
- [ %応答 の`本体$rsの`伝送-済み~byte数$bd ] ~INCBY [ %~byte列 の長さ ] ◎ Increase response’s body’s transmitted bytes with bytes’ length.
- %符号法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 の中へ[[ %~byte列 を包含している `ArrayBuffer$I ]を包装している `Uint8Array$I ~obj ]を`~enqueue$RSする — 例外が投出されたときは ⇒# %~stream をその例外で`~errorにする$RS; 進行中の~fetchを`終了させる$() ◎ Enqueue a Uint8Array object wrapping an ArrayBuffer containing bytes to stream. If that threw an exception, terminate the ongoing fetch, and error stream with that exception.
- ~IF[ %~stream は`もっと~dataが必要$RSではない ]~AND[ %要請 の`同期~flag$rq ~EQ ~OFF ] ⇒ 進行中の~fetchを`休止-$するよう,~UAに請う ◎ If stream doesn’t need more data and request’s synchronous flag is unset, ask the user agent to suspend the ongoing fetch.
- ~ELIF[ %応答 の~message本体~用の~byte列の伝送は,正常に終えられた ] ⇒ ~IF[ %~stream は`読取可$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^i ~EQ ~ON ]: ◎ Let aborted be the termination’s aborted flag. ◎ If aborted is set, then:
- %応答 の`中止~flag$rs ~SET ~ON ◎ Set response’s aborted flag.
- ~IF[ %~stream は`読取可$RSである ] ⇒ %~stream を `AbortError$E 例外で`~errorにする$RS ◎ If stream is readable, error stream with an "AbortError" DOMException.
- ~ELIF[ %~stream は`読取可$RSである ] ⇒ %~stream を `TypeError^E で`~errorにする$RS ◎ 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する~SHOULDである — そうすると処理能が悪化するときは除いて ◎ 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.7. ~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 perform a CORS-preflight fetch using 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, `~tainted生成元~flag$rq ~SET %要請 の`~tainted生成元~flag$rq ◎ 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, and tainted origin flag is request’s tainted origin flag.
注記: %予行 の`~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を設定する$( `Access-Control-Request-Method$h / %要請 の`~method$rq ) ◎ Set `Access-Control-Request-Method` to request’s method in preflight’s header list.
- %~header~list ~LET %要請 の`~header~list$rqに含まれる[ `~CORS安全な要請~header$を除く,すべての`~header$ ]の各`名前$hdを[ 重複は排除し, 字句順に整列し, `~byte小文字~化$した結果 ]からなる~list ◎ Let headers be the names of request’s header list’s headers, excluding CORS-safelisted request-headers and duplicates, sorted lexicographically, and byte-lowercased.
-
~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 / %値 ) ◎ Set `Access-Control-Request-Headers` to value in 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.
- %応答 ~LET ( %~CORS~flag ~SET ~ON ) を与える下で, %予行 を用いて`~HTTP~network-or-cache~fetch$を遂行した結果 ◎ Let response be the result of performing an HTTP-network-or-cache fetch using preflight with the CORS flag set.
-
~IF [ `~CORS検査$( %要請, %応答 ) ~EQ `成功^i ]~AND[ %応答 の`~status$rs は`~ok~status$である ]: ◎ 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名s ~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名s ~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 ~ON ] ⇒ %~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 ~ON ]であることに因り生じる`~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名s 内のある名前を`名前に持つ~header$である ] ⇒ ~CONTINUE
- ~IF[ %~header は`~CORS非~wildcard要請~header名$を`名前に持つ~header$である ] ⇒ ~RET `~network~error$
- ~IF[ %~header は`~CORS安全な要請~header$である ]~AND[[ %要請 の`資格証~mode$rq ~EQ `include^l ]~OR[ `*^bl ~NIN %~header名s ]] ⇒ ~RET `~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 0 ◎ If max-age is failure or null, then set max-age to zero.
- ~IF[ %寿命 ~LT 環境により課される`寿命$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たち ~NEQ ε ] ⇒ %~entryたち を成す各~entryに対し ⇒ その`寿命$cc ~SET %寿命
- ~ELSE ⇒ `新たな~cache~entryを作成する$( %要請, %寿命, %~method, ~NULL )
-
%~header名s 内の ~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.8. ~CORS予行~cache
`~CORS予行~cache@ は, 0 個以上の~entryからなる — その各~entryは,次の~fieldを有する:
- `直列化-済み生成元@cc
- `~byte列$。
- `~url@cc
- `~URL$。
- `寿命@cc
- 秒数。
- `資格証の有無@cc
- 次のいずれか ⇒# `有り^i, `無し^i
- `~method@cc
- 次のいずれか ⇒# ~NULL, `*^bl, `~method$
- `~header名@cc
- 次のいずれか ⇒# ~NULL, `*^bl, `~header$の`名前$hd
【 `~method$ccと`~header名$ccは,両立しない~fieldであり、常に,一方は ~NULL, 他方は非 ~NULL になる。 】
各~entryは、`~CORS予行~cache$に~~追加された時点から,その`寿命$cc~fieldに指定された秒数が経過するまでに、除去され~MUST。 経過する前に除去されても~MAY。 ◎ Entries must be removed after the seconds specified in the max-age field have passed since storing the entry. Entries may be removed before that moment arrives.
`新たな~cache~entryを作成する@ ときは、所与の ( %要請, %寿命, %~method, %~header名 ) に対し,次のように設定された~entryを`~CORS予行~cache$内に作成する ⇒# `直列化-済み生成元$cc ~SET `要請の生成元を直列化する$( %要請 ), `~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 entry in the CORS-preflight cache, given request, max-age, method, and headerName, do so as follows: ◎ serialized origin • The result of 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
`~cache~entryを消去する@ ときは、所与の ( %要請 ) に対し ⇒ `~CORS予行~cache$から,次を満たす~entryたちを除去する ⇒ [ ~entryの`直列化-済み生成元$cc ~EQ `要請の生成元を直列化する$( %要請 ) ]~AND[ ~entryの`~url$cc ~EQ %要請 の`現在の~url$rq ] ◎ To clear cache entries, given a request, remove any entries in the CORS-preflight cache whose serialized origin is the result of serializing a request origin with request and whose url is request’s current url.
次をすべて満たす~entryは、 %要請 に `~cache合致する@ とされる: ◎ There is a cache match for request if\
- `直列化-済み生成元$cc ~EQ `要請の生成元を直列化する$( %要請 ) ◎ serialized origin is the result of serializing a request origin with request,\
- `~url$cc ~EQ %要請 の`現在の~url$rq ◎ url is request’s current url,\
-
次のいずれかが満たされる:
- `資格証の有無$cc ~EQ `有り^i
- [ `資格証の有無$cc ~EQ `無し^i ]~AND[ %要請 の`資格証~mode$rq ~NEQ `include^l ]
`~methodも合致している~cache~entry@ は、所与の ( %要請, %~method ) に対し,次を満たす~entryが`~CORS予行~cache$に[ 在るならば それ(ら)† / 無いならば ε ]を返す ⇒ [ %要請 に`~cache合致する$ ]~AND[ `~method$cc ~IN { %~method, `*^bl } ] ◎ There is a method cache match for method using request when there is an entry in CORS-preflight cache for which there is a cache match for request and its method is method or `*`.
【† 原文からは、該当する~entryは高々 1 個のようにも読み取れそうだが,複数あり得るかもしれない — はっきりしないので、この用語を利用している箇所も含め,複数あり得るとみなして訳している。 次の用語も同様。 】
`~header名も合致している~cache~entry@ は、所与の ( %要請, %~header名 ) に対し,次を満たす~entryが`~CORS予行~cache$に[ 在るならば それ(ら) / 無いならば ε ]を返す ⇒ [ %要請 に`~cache合致する$ ]~AND[ ( ~entryの`~header名$cc %H, %~header名 ) は次のいずれかを満たす ]: ◎ There is a header-name cache match for headerName using request when there is an entry in CORS-preflight cache for which there is a cache match for request and\
- %H は %~header名 に`~byte大小無視$で合致する
- [ %H ~EQ `*^bl ]~AND[ %~header名 は`~CORS非~wildcard要請~header名$でない ]
4.9. ~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 extracting header list values given `Access-Control-Allow-Origin` and response’s header list.
~network~errorに対しては — ~headerが無いので — これは失敗することになる。 ◎ The above will fail for network errors, as they have no headers.
-
~IF[ %生成元 ~IN { ~NULL, `失敗^i } ] ⇒ ~RET `失敗^i ◎ If origin is null or failure, 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 `*`, return success.
- ~IF [ `要請の生成元を直列化する$( %要請 ) ~NEQ %生成元 ] ⇒ ~RET `失敗^i ◎ If the result of 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", return success.
- %資格証 ~LET `~header~listから値を抽出する$( %応答 の`~header~list$rs, `Access-Control-Allow-Credentials$h ) ◎ Let credentials be the result of extracting header list values given `Access-Control-Allow-Credentials` and response’s header list.
- ~IF[ %資格証 ~EQ `true^bl ] ⇒ ~RET `成功^i ◎ If credentials is `true`, 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 resources:
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$I>> or record<`ByteString$I, `ByteString$I> ) `HeadersInit@I; [`Headers$mC(optional `HeadersInit$I %init), Exposed=(Window,Worker)] interface `Headers@I { void `append$m(`ByteString$I %name, `ByteString$I %value); void `delete$m(`ByteString$I %name); `ByteString$I? `get$m(`ByteString$I %name); boolean `has$m(`ByteString$I %name); void `set$m(`ByteString$I %name, `ByteString$I %value); `iterable$m<`ByteString$I, `ByteString$I>; };
注記: `~header~list$と違って, `Headres$I ~objは複数個の `Set-Cookie$h `~header$は表現できない。 `Set-Cookie^h ~headerは 他のすべての~headerと違って結合できないので,これは ある面で問題になり得るが、この~headerは ~client側~JSには公開されないので,これは受容-可能な妥協点と判断される。 実装は、`~header~list$用であっても — `Set-Cookie^h ~header用の~data構造も~supportする限り — より効率的な `Headres$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 chose 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は、種々の~JS~data構造で初期化できる: ◎ A Headers object can be initialized with various JavaScript data structures:
/* 次の~codeは: */ var %meta = { "Content-Type": "text/xml", "Breaking-Bad": "<3" } new Headers(%meta) /* 次と等価になる: ◎ The above is equivalent to */ var %meta = [ [ "Content-Type", "text/xml" ], [ "Breaking-Bad", "<3" ] ] new Headers(%meta)
`Headers$I ~objには,次のものが結付けられる: ◎ ↓
- `~header~list@Hl(初期~時は空)
- `~header~list$。 ◎ A Headers object has an associated header list (a header list), which is initially empty. This can be a pointer to the header list of something else, e.g., of a request as demonstrated by Request objects.
- 注記: これは、何か他の~objの`~header~list$を指すこともある。 例えば `Request$I ~objの`要請$のそれを指すなど。 ◎ ↑
- `~guard@Hl(初期~時は `none^l )
- 次のいずれか ⇒# `immutable^l, `request^l, `request-no-cors^l, `response^l, `none^l ◎ A Headers object also has an associated guard, which is "immutable", "request", "request-no-cors", "response" or "none".
`新たな~Headers@( %~guard, %~list ) という表記は、次のようにされた,新たな `Headers$I ~objを表すとする:
- `~guard$Hl ~SET %~guard
- %~list が省略されていない場合は、前項に加えて ⇒ `~header~list$Hl ~SET %~list
【 この表記は、簡潔に述べるために,この訳に導入したものである。 】
`~guardで検査する@ ときは、所与の ( %name, %value, `~guard$Hl %~guard ) に対し,次を走らす:
【 この~algoは、共通の記述を集約するため,この訳に導入したものである。 】
- ~IF[ %name は`名前$hdでない ]~OR[ %value は`値$hdでない ] ⇒ ~THROW `TypeError^E
-
%~guard に応じて:
- `immutable^l
- ~THROW `TypeError^E
- `request^l
- ~IF[ %name は`禁止~header名$である ] ⇒ ~RET `不合格^i
- `request-no-cors^l
- ~IF[ ( %name / %value ) は`~CORS安全な要請~header$でない ] ⇒ ~RET `場合によっては合格^i
- `response^l
- ~IF[ %name は`禁止~応答~header名$である ] ⇒ ~RET `不合格^i
- ~RET `合格^i
`Headers$I ~obj %headers に ( `名前$hd %name / `値$hd %value ) の組を `付加する@Hl ときは、次を走らす: ◎ To append a name/value (name/value) pair to a Headers object (headers), run these steps:
- %value ~SET `値を正規化する$( %value ) ◎ Normalize value.
- ~IF[ `~guardで検査する$( %name, %value, %headers の`~guard$Hl ) ~NEQ `合格^i ] ⇒ ~RET ◎ If name is not a name or value is not a value, then throw a TypeError. ◎ If guard is "immutable", then throw a TypeError. ◎ Otherwise, if guard is "request" and name is a forbidden header name, return. ◎ Otherwise, if guard is "request-no-cors" and name/value is not a CORS-safelisted request-header, then return. ◎ Otherwise, if guard is "response" and name is a forbidden response-header name, return.
- %headers の`~header~list$Hlに`~headerを付加する$( %name / %value ) ◎ Append name/value to header list.
- ~IF[ %headers の`~guard$Hl ~EQ `request-no-cors^l ] ⇒ %headers から`特権的~no-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`連列~型$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型$idlである ) ⇒ %~obj 内の ~EACH( %~key → %値 ) に対し ⇒ %headers に ( %~key / %値 ) を`付加する$Hl ◎ Otherwise, object is a record, then for each key → value in object, append key/value to headers.
`Headres$I ~obj %headers から `特権的~no-cors要請~headerを除去する@ ときは、次を走らす: ◎ To remove privileged no-cors request headers from a Headers object (headers), run these steps:
- `特権的~no-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.
- `Headers(init)@m
-
この構築子の被呼出時には、次を走らせ~MUST: ◎ The Headers(init) constructor, when invoked, must run these steps:
- %headers ~LET `新たな~Headers$( `none^l ) ◎ Let headers be a new Headers object whose guard is "none".
- ~IF[ %init は与えられている ] ⇒ %headers を %init で`埋める$Hl ◎ If init is given, fill headers with init.
- ~RET %headers ◎ Return headers.
- `append(name, value)@m
- 被呼出時には、次を走らせし~MUST ⇒ 此れに ( %name / %value ) を`付加する$Hl ◎ The append(name, value) method, when invoked, must append name/value to context object.
- `delete(name)@m
-
被呼出時には、次を走らせ~MUST: ◎ The delete(name) method, when invoked, must run these steps:
-
`~guardで検査する$( %name, `invalid^bl, 此れの`~guard$Hl ) の結果に応じて
- `不合格^i ⇒ ~RET
- `場合によっては合格^i ⇒ ~IF[ %name は`特権的~no-cors要請~header名$でない ] ⇒ ~RET
注記: `invalid^bl を利用するのは、 `delete()^m の引数に %value が渡されないためである。
◎ If name is not a name, then throw a TypeError. ◎ If guard is "immutable", then throw a TypeError. ◎ Otherwise, if guard is "request" and name is a forbidden header name, return. ◎ Otherwise, if guard is "request-no-cors", name/`invalid` is not a CORS-safelisted request-header, and name is not a privileged no-cors request-header name, then return. ◎ `invalid` is used because delete() is not passed a value as argument. ◎ Otherwise, if guard is "response" and name is a forbidden response-header name, return. - ~IF[ `~header~list$Hl内に[ %name を`名前に持つ~header$ ]は無い ] ⇒ ~RET ◎ If header list does not contain name, then return.
- 此れの`~header~list$Hlから`~headerを削除する$( %name ) ◎ Delete name from header list.
- ~IF[ 此れの`~guard$Hl ~EQ `request-no-cors^l ] ⇒ 此れから`特権的~no-cors要請~headerを除去する$ ◎ If guard is "request-no-cors", then remove privileged no-cors request headers from the context object.
-
- `get(name)@m
-
被呼出時には、次を走らせ~MUST: ◎ The get(name) method, when invoked, must run these steps:
- ~IF[ %name は`名前$hdでない ] ⇒ ~THROW `TypeError^E ◎ If name is not a name, then throw a TypeError.
- ~IF[ 此れの`~header~list$Hl内に[ %name を`名前に持つ~header$ ]は無い ] ⇒ ~RET ~NULL ◎ If header list does not contain name, then return null.
- ~RET 此れの`~header~list$Hl 内の %name に対する`結合-済みの値$hd ◎ Return the combined value given name and header list. ↑
- `has(name)@m
-
被呼出時には、次を走らせ~MUST: ◎ The has(name) method, when invoked, must run these steps:
- ~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 header list contains name, and false otherwise.
- `set(name, value)@m
-
被呼出時には、次を走らせ~MUST: ◎ The set(name, value) method, when invoked, must run these steps:
- %value ~SET `値を正規化する$( %value ) ◎ Normalize value.
- ~IF[ `~guardで検査する$( %name, %value, 此れの`~guard$Hl ) ~NEQ `合格^i ] ⇒ ~RET ◎ If name is not a name or value is not a value, then throw a TypeError. ◎ If guard is "immutable", then throw a TypeError. ◎ Otherwise, if guard is "request" and name is a forbidden header name, return. ◎ Otherwise, if guard is "request-no-cors" and name/value is not a CORS-safelisted request-header, then return. ◎ Otherwise, if guard is "response" and name is a forbidden response-header name, return.
- 此れの`~header~list$Hl内で`~headerを設定する$( %name / %value ) ◎ Set name/value in header list.
- ~IF[ `~guard$Hl ~EQ `request-no-cors^l ] ⇒ 此れから`特権的~no-cors要請~headerを除去する$ ◎ If guard is "request-no-cors", then remove privileged no-cors request headers from the context object.
- `iterable@m
- `反復される値~pair$idlは、次の結果で与えられる ⇒ `~header~list$Hlを`整列して結合する$ ◎ The value pairs to iterate over are the return value of running sort and combine with the header list.
5.2. `Body^I ~mixin
typedef ( `Blob$I or `BufferSource$I or `FormData$I or `URLSearchParams$I or `ReadableStream$I or `USVString$I ) `BodyInit@I;
`本体と内容~型を抽出する@ ときは、所与の ( %~obj, %~keepalive~flag (省略時は ~OFF )) に対し,次を走らす — この手続きは ( `本体$, `Content-Type$h `値$hd ) の組を返す: ◎ To extract a body and a `Content-Type` value from object, with an optional keepalive flag, run these steps:
- %~stream ~LET `~ReadableStream~objを構築する$RS() ◎ Let stream be the result of constructing a ReadableStream object.
- %内容~型 ~LET ~NULL ◎ Let Content-Type be null.
- %動作 ~LET ~NULL ◎ Let action be null.
- %~source ~LET ~NULL ◎ Let source be null.
-
%~obj の型に応じて: ◎ Switch on object’s type:
- `Blob$I
-
- %動作 ~SET %~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.
- %~source ~SET %~obj ◎ Set source to object.
- `BufferSource$I
-
- %~stream の中へ[[[ %~obj に保持されている~byte列の複製 ]を包含している `ArrayBuffer$I ]を包装している `Uint8Array$I ~obj ]を`~enqueue$RSする
- %~stream を`~closeする$RS
- %~source ~SET %~obj
例外が投出されたときは ⇒ %~stream をその例外で`~errorにする$RS
◎ Enqueue a Uint8Array object wrapping an ArrayBuffer containing a copy of the bytes held by object to stream and close stream. If that threw an exception, error stream with that exception. ◎ Set source to object. - `FormData$I
-
- %動作 ~SET 次を走らす動作 ⇒ `~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
- %動作 により生成されることになる `~mp_form_data境界~文字列$
- %~source ~SET %~obj ◎ Set source to object.
- `URLSearchParams$I
-
- %動作 ~SET 次を走らす動作 ⇒ `~form_urlencoded直列化器$( %~obj の`名値~組~list$url ) ◎ 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`.
- %~source ~SET %~obj ◎ Set source to object.
- `USVString$I
-
- %動作 ~SET 次を走らす動作 ⇒ `~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`.
- %~source ~SET %~obj ◎ Set source to object.
- `ReadableStream$I
- %~stream ~SET %~obj ◎ Set stream to object.
- ~IF[ %~keepalive~flag ~EQ ~ON ]~AND[ %~obj は `ReadableStream$I 型である ] ⇒ ~THROW `TypeError^E ◎ If keepalive flag is set and object’s type is a ReadableStream object, then throw a TypeError.
-
~IF[ %動作 ~NEQ ~NULL ] ⇒ %動作 を`並列的$に走らす: ◎ If action is non-null, run action in parallel:
- 1 個以上の~byte %~byte列 が可用になる度に ⇒ %~stream の中へ[[ %~byte列 を包含している `ArrayBuffer$I ]を包装している `Uint8Array$I ~obj ]を`~enqueue$RSする ⇒ `ArrayBuffer$I の作成-時に例外が投出されたときは ⇒# %~stream をその例外で`~errorにする$RS; 走っている %動作 を取消す ◎ Whenever one or more bytes are available, let bytes be the bytes and enqueue a Uint8Array object wrapping an ArrayBuffer containing bytes to stream. If creating the ArrayBuffer threw an exception, error stream with that exception and cancel running action.
- %動作 を走らせ終えたときは ⇒ %~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.
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$I> `text$m(); };
注記: ~HTMLなど,~network層に依存させたくない内容形式が、ここで公開されることにはならないであろう。 むしろ、~HTML構文解析器~APIが,~streamを受容するようになるであろう。 【参考】 ◎ 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 ~mixinを実装している各~objには、次のものが結付けられる:
- `本体@Bd
- ~NULL または `本体$。
- `~MIME型@Bd
- 初期~時は 空~byte列。
`Body$I ~mixinを実装している~objは、その`本体$Bd %本体 が: ◎ ↓
- [ %本体 ~NEQ ~NULL ]~AND[ %本体 の`~stream$bdは`妨げられている$RS ]とき, `妨げられている@Bd という。 ◎ An object implementing the Body mixin is said to be disturbed if body is non-null and its stream is disturbed.
- [ %本体 ~NEQ ~NULL ]~AND[ %本体 の`~stream$bdは`~lockされている$Bd ]とき, `~lockされている@Bd という。 ◎ An object implementing the Body mixin is said to be locked if body is non-null and its stream is locked.
- `body@m
- 取得子は、次を返さ~MUST ⇒ 此れの`本体$Bd ~NEQ ~NULL ならば その`~stream$bd / ~ELSE_ ~NULL ◎ The body attribute’s getter must return null if body is null and body’s stream otherwise.
- `bodyUsed@m
- 取得子は、次を返さ~MUST ⇒ 此れは`妨げられている$Bdならば ~T / ~ELSE_ ~F ◎ The bodyUsed attribute’s getter must return true if disturbed, and false otherwise.
`Body$I ~mixinを実装している各~objには、 `~dataを梱包する@Bd ~algoも結付けられる。 それは、所与の ( %~byte列, %型, %~MIME型 ) に対し, %型 に応じて次を走らす: ◎ Objects implementing the Body mixin also have an associated package data algorithm, given bytes, a 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 %~byte列 を内容とする, [ `type$mF 属性 ~SET %~MIME型 ]にされた `Blob$I ◎ Return a Blob whose contents are bytes and type attribute is mimeType.
- `FormData^i
-
%~MIME型 の~parameterを除いた部分に応じて: ◎ ↓
- `multipart/form-data^bl ◎ If mimeType (ignoring parameters) 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に構文解析され~MUST: ◎ 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 節に定義される既定) ]
- 包含しない場合
- `~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 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^bl ◎ Otherwise, if mimeType (ignoring parameters) is `application/x-www-form-urlencoded`, then:
-
- %~entries ~LET `~form_urlencoded構文解析器$( %~byte列 ) ◎ Let entries be the result of parsing bytes.
- ~IF[ %~entries ~EQ `失敗^i ] ⇒ ~THROW `TypeError^E ◎ If entries is failure, then throw a TypeError.
- ~ELSE ⇒ ~RET 次のようにされた,新たな `FormData$I ~obj ⇒ `~entry$xhrの~list ~SET %~entries ◎ Return a new FormData object whose entries are entries.
- その他
- ~THROW `TypeError^E ◎ Otherwise, throw a TypeError.
- `JSON^i
- ~RET `~byte列を~JSONとして構文解析する$( %~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.
`Body$I ~mixinを実装している各~obj %O には、 `本体を消費する@Bd ~algoも結付けられる — それは、所与の ( %型 ) に対し,次を走らす: ◎ Objects implementing the Body mixin also have an associated consume body algorithm, given a type, runs these steps:
- ~IF[ %O は`妨げられている$Bd ]~OR[ %O は`~lockされている$Bd ] ⇒ ~RET `TypeError^E で`却下される新たな~promise$ ◎ If this object is disturbed or locked, return a new promise rejected with a TypeError.
- %~stream ~LET [ %O の`本体$Bd ~NEQ ~NULL ならば その`~stream$bd / ~ELSE_ `空の~ReadableStream~obj$ ] ◎ Let stream be body’s stream if body is non-null, or an empty ReadableStream object otherwise.
- %読取器 ~LET `読取器を取得する$RS( %~stream ) ⇒ 例外が投出されたときは ⇒ ~RET その例外で`却下される新たな~promise$ ◎ Let reader be the result of getting a reader from stream. If that threw an exception, return a new promise rejected with that exception.
- %~promise ~LET %~stream から %読取器 で`すべての~byte列を読取った$RS結果 ◎ Let promise be the result of reading all bytes from stream with reader.
-
~RET [ 次を走らす充足~handler ]で %~promise を`変形-$した結果:
- ~RET `~dataを梱包する$Bd( ~handlerの最初の引数, %型, %O の`~MIME型$Bd )
- `arrayBuffer()@m
- 被呼出時には、次の結果を返さ~MUST ⇒ `本体を消費する$Bd( `ArrayBuffer^i ) ◎ The arrayBuffer() method, when invoked, must return the result of running consume body with ArrayBuffer.
- `blob()@m
- 被呼出時には、次の結果を返さ~MUST ⇒ `本体を消費する$Bd( `Blob^i ) ◎ The blob() method, when invoked, must return the result of running consume body with Blob.
- `formData()@m
- 被呼出時には、次の結果を返さ~MUST ⇒ `本体を消費する$Bd( `FormData^i ) ◎ The formData() method, when invoked, must return the result of running consume body with FormData.
- `json()@m
- 被呼出時には、次の結果を返さ~MUST ⇒ `本体を消費する$Bd( `JSON^i ) ◎ The json() method, when invoked, must return the result of running consume body with JSON.
- `text()@m
- 被呼出時には、次の結果を返さ~MUST ⇒ `本体を消費する$Bd( `text^i ) ◎ The text() method, when invoked, must return the result of running consume body with text.
5.3. `Request^I ~class
typedef (`Request$I or `USVString$I) `RequestInfo@I;
[`Request$mC(
`RequestInfo$I %input,
optional `RequestInit$I %init
), Exposed=(Window,Worker)]
interface `Request@I {
readonly attribute `ByteString$I `method$m;
readonly attribute `USVString$I `url$m;
[SameObject] readonly attribute `Headers$I `headers$m;
readonly attribute `RequestDestination$I `destination$m;
readonly attribute `USVString$I `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$I `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$I `method@RqI;
`HeadersInit$I `headers@RqI;
`BodyInit$I? `body@RqI;
`USVString$I `referrer@RqI;
`ReferrerPolicy$I `referrerPolicy@RqI;
`RequestMode$I `mode@RqI;
`RequestCredentials$I `credentials@RqI;
`RequestCache$I `cache@RqI;
`RequestRedirect$I `redirect@RqI;
`DOMString$I `integrity@RqI;
boolean `keepalive@RqI;
`AbortSignal$I? `signal@RqI;
any `window@RqI; // 設定できるのは ~NULL に限られる。
};
enum `RequestDestination@I {
"", "audio", "audioworklet", "document", "embed", "font", "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
- `AbortSignal$I ~obj — 初期~時は 新たな `AbortSignal$I ~obj。 ◎ A Request object has an associated signal (an AbortSignal object), initially a new AbortSignal object.
`Request$I ~objの`本体$Bdは、その`要請$Rqの`本体$rqである。 ◎ A Request object’s body is its request’s body.
- %request = new `Request$m(%input [, %init ])
- 新たな %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 を次のいずれかに設定する ⇒# `Headres$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.
- `credentials$RqI
- %request の `credentials$m を設定する文字列 — 要請に伴う資格証は、次のいずれになるかを指示する ⇒# 常に送信される, 決して送信されない, 同一生成元~URLに限り送信される ◎ A string indicating whether credentials will be sent with the request always, never, or only when sent to a same-origin URL. Sets request’s credentials.
- `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絞込み応答$として返す ◎ 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からなる `Headres$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 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を与える。 その値は、空白で区切られた いくつかの~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 が[ (前後~頁への)履歴~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(input, init)@m 構築子は、次を走らせ~MUST: ◎ The Request(input, init) constructor must run these steps:
- %要請 ~LET ~NULL ◎ Let request be null.
- %~fallback~mode ~LET ~NULL ◎ Let fallbackMode be null.
- %~fallback資格証 ~LET ~NULL ◎ Let fallbackCredentials be null.
- %基底~URL ~LET `現在の設定群~obj$の`~API用~基底~URL$enV ◎ Let baseURL be current 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 は`資格証を含む$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".
- %~fallback資格証 ~SET `same-origin^l ◎ Set fallbackCredentials to "same-origin".
-
~ELSE ( %input は `Request$I ~objである ) : ◎ Otherwise (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 current 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, set window to request’s window.
- ~IF[ %init に `window$RqI ~memberは`在する$idl ]~AND[ その~member値 ~NEQ ~NULL ] ⇒ ~THROW `TypeError^E ◎ If init’s window member is present and it is non-null, then throw a TypeError.
- ~IF[ %init に `window$RqI ~memberは`在する$idl ] ⇒ %~window ~SET `no-window^l ◎ If init’s window member is present, set window to "no-window".
- %要請 ~SET 次のように設定された,新たな`要請$ ⇒# `~url$rq ~SET %要請 の`現在の~url$rq, `~method$rq ~SET %要請 の`~method$rq, `~header~list$rq ~SET %要請 の`~header~list$rqの複製, `非安全-要請~flag$rq ~SET ~ON, `~client$rq ~SET `現在の設定群~obj$, `~window$rq ~SET %~window, `生成元$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~flag$rq ~SET %要請 の`~keepalive~flag$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 • Current settings object. window • window. 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 flag • request’s keepalive flag. reload-navigation flag • request’s reload-navigation flag. history-navigation flag • request’s history-navigation flag.
-
~IF[ %init には,いずれかの 【 `RequestInit$I 】 ~memberは`在する$idl ]: ◎ If any of init’s members are present, 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 ~OFF, `履歴~navi~flag$rq ~SET ~OFF, `~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.
-
~IF[ %init に `referrer$RqI ~memberは`在する$idl ]: ◎ If init’s referrer member is present, then:
- %~referrer ~LET %init の `referrer$RqI ~memberの値 ◎ Let referrer be init’s referrer member.
- ~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 conditions is true, then set request’s referrer to "client":
-
%解析済み~referrer は次をいずれも満たす
- `~cannot-be-a-base-URL~flag$url ~EQ ~ON
- `~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 ◎ ↑
-
- ~ELSE ⇒ %要請 の`~referrer$rq ~SET %解析済み~referrer ◎ Otherwise, set request’s referrer to parsedReferrer.
-
~IF[ %init に `referrerPolicy$RqI ~memberは`在する$idl ] ⇒ %要請 の`~referrer施策$rq ~SET その~member値 ◎ If init’s referrerPolicy member is present, set request’s referrer policy to it.
- %~mode ~LET [ %init に `mode$RqI ~memberは`在する$idlならば その~member値 / ~ELSE_ %~fallback~mode ] ◎ Let mode be init’s mode member if it is present, 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.
- %資格証 ~LET [ %init に `credentials$RqI ~memberは`在する$idlならば その~member値 / ~ELSE_ %~fallback資格証 ] ◎ Let credentials be init’s credentials member if it is present, and fallbackCredentials otherwise.
- ~IF[ %資格証 ~NEQ ~NULL ] ⇒ %要請 の`資格証~mode$rq ~SET %資格証 ◎ If credentials is non-null, set request’s credentials mode to credentials.
- ~IF[ %init に `cache$RqI ~memberは`在する$idl ] ⇒ %要請 の`~cache~mode$rq ~SET その~member値 ◎ If init’s cache member is present, 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 ~memberは`在する$idl ] ⇒ %要請 の`~redirect~mode$rq ~SET その~member値 ◎ If init’s redirect member is present, set request’s redirect mode to it.
- ~IF[ %init に `integrity$RqI ~memberは`在する$idl ] ⇒ %要請 の`完全性~metadata$rq ~SET その~member値 ◎ If init’s integrity member is present, set request’s integrity metadata to it.
- %要請 の`~keepalive~flag$rq ~SET [ 次が満たされるならば ~ON / ~ELSE_ ~OFF ] ⇒ [ %init に `keepalive$RqI ~memberは`在する$idl ]~AND[ その~member値 ~EQ ~T ] ◎ If init’s keepalive member is present, then set request’s keepalive flag if init’s keepalive member is true, and unset it otherwise.
-
~IF[ %init に `method$RqI ~memberは`在する$idl ]: ◎ If init’s method member is present, then:
- %~method ~LET その~member値 ◎ Let method be init’s method member.
- ~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 ~SET `~methodを正規化する$( %~method ) ◎ Normalize method.
- %要請 の`~method$rq ~SET %~method ◎ Set request’s method to method.
- ~IF[ %init に `signal$RqI ~memberは`在する$idl ] ⇒ %通達 ~SET その~member値 ◎ If init’s signal member is present, then set signal to it.
- %R ~LET 新たな `Request$I ~obj ◎ Let r be a new Request object associated with request.
- %R の`要請$Rq ~SET %要請 ◎ ↑
-
~IF[ %通達 ~NEQ ~NULL ] ⇒ `通達に追従させる$( %R の`通達$Rq, %通達 ) ◎ If signal is not null, then make r’s signal follow signal.
- %R の`~Headers$Rq ~SET `新たな~Headers$( `request^l, %要請 の`~header~list$rq ) ◎ Set r’s headers to a new Headers object, whose header list is request’s header list, and guard is "request".
-
~IF[ %init 内に何らかの~memberは在する ]: ◎ If any of init’s members are present, then:
注記: %headers は,この~mode【 %~mode? 】では許容されない~headerを包含するかもしれないので、この段で無毒化される。 他の場合、それは以前に無毒化されたか,特権的~APIによる作成-時から改変されてない。 ◎ The headers are sanitised as they might contain headers that are not allowed by this mode. Otherwise, they were previously sanitised or are unmodified since creation by a privileged API.
- %headers ~LET %R の`~Headers$Rqの複製 — `~header~list$Hlも含めて複製する ◎ Let headers be a copy of r’s headers and its associated header list.
- ~IF[ %init に `headers$RqI ~memberは`在する$idl ] ⇒ %headers ~SET %init の `headers$RqI ~member ◎ If init’s headers member is present, set headers to init’s headers member.
- %R の`~Headers$Rqの`~header~list$Hlを空にする ◎ Empty r’s headers’s header list.
-
~IF[ %R の`要請$Rqの`~mode$rq ~EQ `no-cors^l ]: ◎ If r’s request’s mode is "no-cors", then:
- ~IF[ %R の`要請$Rqの`~method$rqは `~CORS安全な~method$でない ] ⇒ ~THROW `TypeError^E ◎ If r’s request’s method is not a CORS-safelisted method, then throw a TypeError.
- %R の`~Headers$Rqの`~guard$Hl ~SET `request-no-cors^l ◎ Set r’s headers’s guard to "request-no-cors".
- ~IF[ %headers は `Headers$I ~objである ] ⇒ %headers の`~header~list$Hl内の ~EACH( %~header ) に対し ⇒ %R の`~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 r’s Headers object.
- ~ELSE ⇒ %R の`~Headers$Rqを %headers で`埋める$Hl ◎ Otherwise, fill r’s Headers object 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, and null otherwise.
- %本体~member ~LET [ %init に `body$RqI ~memberは`在する$idl ならば その~member値 / ~ELSE_ ~NULL ] ◎ ↓
- ~IF[[ %本体~member ~NEQ ~NULL ]~OR[ %入力~本体 ~NEQ ~NULL ]]~AND[ %要請 の`~method$rq ~IN { `GET$hm, `HEAD$hm } ] ⇒ ~THROW `TypeError^E ◎ If either init’s body member is present and is non-null or inputBody is non-null, and request’s method is `GET` or `HEAD`, then throw a TypeError.
- %本体 ~LET %入力~本体 ◎ Let body be inputBody.
-
~IF[ %本体~member ~NEQ ~NULL ]: ◎ If init’s body member is present and is non-null, then:
- %内容~型 ~LET ~NULL ◎ Let Content-Type be null.
- ~IF[ %init に `keepalive$RqI ~memberは`在する$idl ]~AND[ その~member値 ~EQ ~T ] ⇒ ( %本体, %内容~型 ) ~SET `本体と内容~型を抽出する$( %本体~member, ~keepalive~flag ~SET ~ON ) ◎ If init’s keepalive member is present and is true, then set body and Content-Type to the result of extracting init’s body member, with keepalive flag set.
- ~ELSE ⇒ ( %本体, %内容~型 ) ~SET `本体と内容~型を抽出する$( %本体~member ) ◎ Otherwise, set body and Content-Type to the result of extracting init’s body member.
- ~IF [ %内容~型 ~NEQ ~NULL ]~AND[[ %R の`~Headers$Rqの`~header~list$Hl ]内に[ `Content-Type$h を`名前に持つ~header$ ]は無い ] ⇒ %R の`~Headers$Rqに ( `Content-Type$h / %内容~型 ) を`付加する$Hl ◎ If Content-Type is non-null and r’s headers’s header list does not contain `Content-Type`, then append `Content-Type`/Content-Type to r’s headers.
-
~IF[ %本体 ~NEQ ~NULL ]~AND[ %本体 の`~source$bd ~EQ ~NULL ]: ◎ If body is non-null and body’s source is null, then:
- ~IF[ %R の`要請$Rqの`~mode$rq ~NIN { `same-origin^l, `cors^l } ] ⇒ ~THROW `TypeError^E ◎ If r’s request’s mode is neither "same-origin" nor "cors", then throw a TypeError.
- %R の`要請$Rqの`~CORS予行~利用~flag$rq ~SET ~ON ◎ Set r’s request’s use-CORS-preflight flag.
- ~IF[ %入力~本体 ~EQ %本体 ]~AND[[ %input は`妨げられている$Bd ]~OR[ %input は`~lockされている$Bd ]] ⇒ ~THROW `TypeError^E ◎ If inputBody is body and input is disturbed or locked, then throw a TypeError.
-
~IF[ %入力~本体 ~NEQ ~NULL ]~AND[ %入力~本体 ~EQ %本体 ]: ◎ If inputBody is non-null and inputBody is body, then:
-
%RS ~LET %入力~本体 の`~stream$bdと正確に同じ~dataを読取れるような `ReadableStream$I ~obj ◎ Let rs bs a ReadableStream object from which one can read the exactly same data as one could read from inputBody’s stream.
これは、 形式変換~stream と ~pipe法 が精確に定義されたなら,より精確に指定されることになる。 この課題 を見よ。 ◎ This will be specified more precisely once transform stream and piping are precisely defined. See the issue.
注記: これは %入力~本体 の`~stream$bdが,即時に[ `~lockされている$RS, かつ `妨げられている$RS ]ようにする。 ◎ This makes inputBody’s stream locked and disturbed immediately.
- %本体 ~SET 次のようにされた,新たな`本体$ ⇒# `~stream$bd ~SET %RS; `~source$bd ~SET %入力~本体 の`~source$bd; `総~byte数$bd ~SET %入力~本体 の`総~byte数$bd ◎ Set body to a new body whose stream is rs, whose source is inputBody’s source, and whose total bytes is inputBody’s total bytes.
-
- %R の`要請$Rqの`本体$rq ~SET %本体 ◎ Set r’s request’s body to body.
- %R の`~MIME型$Bd ~SET `~MIME型を抽出する$( %R の`要請$Rqの`~header~list$rq ) ◎ Set r’s MIME type to the result of extracting a MIME type from r’s request’s header list.
- ~RET %R ◎ Return r.
- `method@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~method$rq ◎ The method attribute’s getter must return request’s method.
- `url@m
- 取得子は、次の結果を返さ~MUST ⇒ `~URLを直列化する$( 此れの`要請$Rqの`~url$rq ) ◎ The url attribute’s getter must return request’s url, serialized.
- `headers@m
- 取得子は、次を返さ~MUST ⇒ 此れの`~Headers$Rq ◎ The headers attribute’s getter must return the associated headers.
- `destination@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`行先$rq ◎ The destination attribute’s getter must return request’s destination.
- `referrer@m
-
取得子は、此れの`要請$Rqの`~referrer$rqに応じて,次を返さ~MUST:
- `no-referrer^l
- 空~文字列
- `client^l
- `about:client^l
- その他
- `~URLを直列化する$( `~referrer$rq )
- `referrerpolicy@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~referrer施策$rq ◎ The referrerPolicy attribute’s getter must return request’s referrer policy.
- `mode@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~mode$rq ◎ The mode attribute’s getter must return request’s mode.
- `credentials@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`資格証~mode$rq ◎ The credentials attribute’s getter must return request’s credentials mode.
- `cache@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~cache~mode$rq ◎ The cache attribute’s getter must return request’s cache mode.
- `redirect@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~redirect~mode$rq ◎ The redirect attribute’s getter must return request’s redirect mode.
- `integrity@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`完全性~metadata$rq ◎ The integrity attribute’s getter must return request’s integrity metadata.
- `keepalive@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~keepalive~flag$rqに応じて ⇒# ~ON ならば ~T / ~OFF ならば ~F ◎ The keepalive attribute’s getter must return true if request’s keepalive flag is set, and false otherwise.
- `isReloadNavigation@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`~reload~navi~flag$rqに応じて ⇒# ~ON ならば ~T / ~OFF ならば ~F ◎ The isReloadNavigation attribute’s getter, when invoked, must return true if the context object’s request’s reload-navigation flag is set, and false otherwise.
- `isHistoryNavigation@m
- 取得子は、次を返さ~MUST ⇒ 此れの`要請$Rqの`履歴~navi~flag$rqに応じて ⇒# ~ON ならば ~T / ~OFF ならば ~F ◎ The isHistoryNavigation attribute’s getter, when invoked, must return true if the context object’s request’s history-navigation flag is set, and false otherwise.
- `signal@m
- 取得子は、次を返さ~MUST ⇒ 此れの`通達$Rq ◎ The signal attribute’s getter must return the associated signal.
- `clone()@m
-
被呼出時には、次を走らせ~MUST: ◎ The clone() method, when invoked, must run these steps:
- ~IF[ 此れは`妨げられている$Bd ]~OR[ 此れは`~lockされている$Bd ] ⇒ ~THROW `TypeError^E ◎ If this Request object is disturbed or locked, then throw a TypeError.
- %~Request~objの~clone ~LET 新たな `Request$I ~obj ◎ Let clonedRequestObject be a new Request object.
- %要請の~clone ~LET `要請を~cloneする$( 此れの`要請$Rq ) ◎ Let clonedRequest be the result of cloning context object’s request.
- %~Request~objの~clone の`要請$Rq ~SET %要請の~clone ◎ Set clonedRequestObject’s request to clonedRequest.
- %~Request~objの~clone の`~Headers$Rq ~SET `新たな~Headers$( 此れの`~Headers$Rqの`~guard$Hl, %要請の~clone の`~header~list$Hl ) ◎ Set clonedRequestObject’s headers to a new Headers object with the following properties: ◎ header list • clonedRequest’s header list. guard • context object’s headers’s guard.
- `通達に追従させる$( %~Request~objの~clone の`通達$Rq, 此れの`通達$Rq ) ◎ Make clonedRequestObject’s signal follow context object’s signal.
- ~RET %~Request~objの~clone ◎ Return clonedRequestObject.
5.4. `Response^I ~class
[`Response$mC( optional `BodyInit$I? %body = null, optional `ResponseInit$I %init ), Exposed=(Window,Worker)] interface `Response@I { [NewObject] static `Response$I `error$m(); [NewObject] static `Response$I `redirect$m( `USVString$I %url, optional unsigned short %status = 302 ); readonly attribute `ResponseType$I `type$m; readonly attribute `USVString$I `url$m; readonly attribute boolean `redirected$m; readonly attribute unsigned short `status$m; readonly attribute boolean `ok$m; readonly attribute `ByteString$I `statusText$m; [SameObject] readonly attribute `Headers$I `headers$m; readonly attribute Promise<`Headers$I> `trailer$m; [NewObject] `Response$I `clone$m(); }; `Response$I includes `Body$I; dictionary `ResponseInit@I { unsigned short `status@RsI = 200; `ByteString$I `statusText@RsI = "OK"; `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.
- `~trailer~promise@Rs
- ~promise。 ◎ A Response object also has an associated trailer promise (a promise).\
- `trailer$m 属性から利用される。 ◎ Used for the trailer attribute.
`新たな~Response@( %応答, %~Headers ) という表記は、次のようにされた,新たな `Response$I ~objを表すとする ⇒# `応答$Rs ~SET %応答, `~Headers$Rs ~SET %~Headers
【 この表記は、簡潔に述べるために,この訳に導入したものである。 】
`Response$I ~objの`本体$Bdは、その`応答$Rsの`本体$rsである。 ◎ A Response object’s body is its response’s body.
- `Response(body, init)@m
-
この構築子の被呼出時には、次を走らせ~MUST: ◎ The Response(body, init) constructor, when invoked, must run these steps:
- ~IF[ %init の `status$RsI ~member ~NIN { `200^st 〜 `599^st } ] ⇒ ~THROW `RangeError^E ◎ If init’s status member is not in the range 200 to 599, inclusive, then throw a RangeError.
- ~IF[ %init の `statusText$RsI ~memberは `reason-phrase$p ~token生成規則に合致しない ] ⇒ ~THROW `TypeError^E ◎ If init’s statusText member does not match the reason-phrase token production, then throw a TypeError.
- %応答 ~LET 新たな`応答$ ◎ ↓
- %R ~LET `新たな~Response$( %応答, `新たな~Headers$( `response^l, %応答 の`~header~list$rs ) ) ◎ Let r be a new Response object associated with a new response. ◎ Set r’s headers to a new Headers object, whose header list is r’s response’s header list, and guard is "response".
- %応答 の`~status$rs ~SET %init の `status$RsI ~member ◎ Set r’s response’s status to init’s status member.
- %応答 の`~status~message$rs ~SET %init の `statusText$RsI ~member ◎ Set r’s response’s status message to init’s statusText member.
- ~IF[ %init に `headers$RsI ~memberは`在する$idl ] ⇒ %R の`~Headers$Rsを %init の `headers$RsI ~memberで`埋める$Hl ◎ If init’s headers member is present, then fill r’s headers with init’s headers member.
-
~IF[ %body ~NEQ ~NULL ]: ◎ If body is non-null, then:
-
~IF[ %init の `status$RsI ~member は`~null本体~status$である ] ⇒ ~THROW `TypeError^E ◎ If init’s status member is a null body status, then throw a TypeError.
注記: `101$st は、他所におけるその利用に因り,`~null本体~status$に含まれているので、この段には影響しない。 ◎ 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.
- ( %R の`応答$Rsの`本体$rs, %内容~型 ) ~SET `本体と内容~型を抽出する$( %body ) ◎ Set r’s response’s body and Content-Type to the result of extracting body.
- ~IF[ %内容~型 ~NEQ ~NULL ]~AND[ %R の`応答$Rsの`~header~list$rs内に[ `Content-Type$h を`名前に持つ~header$ ]は無い ] ⇒ %R の`応答$Rsの`~header~list$rsに`~headerを付加する$( `Content-Type$h / %内容~型 ) ◎ If Content-Type is non-null and r’s response’s header list does not contain `Content-Type`, then append `Content-Type`/Content-Type to r’s response’s header list.
-
- %R の`~MIME型$Bd ~SET `~MIME型を抽出する$( %R の`応答$Rsの`~header~list$rs ) ◎ Set r’s MIME type to the result of extracting a MIME type from r’s response’s header list.
- %R の`応答$Rsの`~HTTPS状態$rs ~SET `現在の設定群~obj$の`~HTTPS状態$enV ◎ Set r’s response’s HTTPS state to current settings object’s HTTPS state.
- `新たな~Headers$( `immutable^l ) で %R の`~trailer~promise$Rsを`解決する$ ◎ Resolve r’s trailer promise with a new Headers object whose guard is "immutable".
- ~RET %R ◎ Return r.
- `error()@m
-
この静的~methodの被呼出時には、次を走らせ~MUST: ◎ The static error() method, when invoked, must run these steps:
- ~RET `新たな~Response$( 新たな`~network~error$, `新たな~Headers$( `immutable^l ) ) ◎ Let r be a new Response object, whose response is a new network error. ◎ Set r’s headers to a new Headers object whose guard is "immutable". ◎ Return r.
- `redirect(url, status)@m
-
この静的~methodの被呼出時には、次を走らせ~MUST: ◎ The static redirect(url, status) method, when invoked, must run these steps:
- %解析済み~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~status$でない ] ⇒ ~THROW `RangeError^E ◎ If status is not a redirect status, then throw a RangeError.
- %応答 ~LET 新たな`応答$ ◎ ↓
- %R ~LET `新たな~Response$( %応答, `新たな~Headers$( `immutable^l ) ) ◎ Let r be a new Response object, whose response is a new response. ◎ Set r’s headers to a new Headers object whose guard is "immutable".
- %応答 の`~status$rs ~SET %status ◎ Set r’s response’s status to status.
- %応答 の`~header~list$rs内で`~headerを設定する$( `Location$h / 次の結果 ) ⇒ `同型に符号化する$( `~URLを直列化する$( %解析済み~URL ) ) ◎ Set `Location` to parsedURL, serialized and isomorphic encoded, in r’s response’s header list.
- ~RET %R ◎ Return r.
- `type@m
- 取得子は、次を返さ~MUST ⇒ 此れの`応答$Rsの`種別$rs ◎ The type attribute’s getter must return response’s type.
- `url@m
-
取得子は、次を走らせ~MUST:
- %~url ~LET 此れの`応答$Rs の`~url$rs
- ~IF[ %~url ~EQ ~NULL ] ⇒ ~RET 空~文字列
- ~RET `~URLを直列化する$( %~url, `素片は除外する^i ) `URL$r
- `redirected@m
- 取得子は、次を返さ~MUST ⇒ 此れの`応答$Rsの`~url~list$rs内に複数の~itemがあるならば ~T / ~ELSE_ ~F ◎ The redirected attribute’s getter must return true if response’s url list has more than one item, and false otherwise.
- 注記: ~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.
- `status@m
- 取得子は、次を返さ~MUST ⇒ 此れの`応答$Rsの`~status$rs ◎ The status attribute’s getter must return response’s status.
- `ok@m
- 取得子は、次を返さ~MUST ⇒ 此れの`応答$Rsの`~status$rsは `~ok~status$である ならば ~T / ~ELSE_ ~F ◎ The ok attribute’s getter must return true if response’s status is an ok status, and false otherwise.
- `statusText@m
- 取得子は、次を返さ~MUST ⇒ 此れの`応答$Rsの`~status~message$rs ◎ The statusText attribute’s getter must return response’s status message.
- `headers@m
- 取得子は、次を返さ~MUST ⇒ 此れの`~Headers$Rs ◎ The headers attribute’s getter must return the associated Headers object.
- `trailer@m
- 取得子は、次を返さ~MUST ⇒ 此れの`~trailer~promise$Rs ◎ The trailer attribute’s getter must return the associated trailer promise.
- `clone()@m
-
被呼出時には、次を走らせ~MUST: ◎ The clone() method, when invoked, must run these steps:
- ~IF[ 此れは`妨げられている$Bd ]~OR[ 此れは`~lockされている$Bd ] ⇒ ~THROW `TypeError^E ◎ If context object is disturbed or locked, then throw a TypeError.
- %応答の~clone ~LET `応答を~cloneする$( 此れの`応答$Rs ) ◎ Let clonedResponseObject be a new Response object. ◎ Let clonedResponse be the result of cloning context object’s response.
- %~Response~objの~clone ~LET `新たな~Response$( %応答の~clone, `新たな~Headers$( 此れの`~Headers$Rsの`~guard$Hl, %応答の~clone の`~header~list$rs ) ) ◎ Set clonedResponseObject’s response to clonedResponse. ◎ Set clonedResponseObject’s headers to a new Headers object whose header list is set to clonedResponse’s header list, and guard is the context object’s headers’s guard.
- 此れの`~trailer~promise$Rsの`充足-時には$ ⇒ `新たな~Headers$( `immutable^l, %応答の~clone の`~trailer$rs ) で %~Response~objの~clone の`~trailer~promise$Rsを`解決する$ ◎ Upon fulfillment of context object’s trailer promise, resolve clonedResponseObject’s trailer promise with a new Headers object whose guard is "immutable", and whose header list is clonedResponse’s trailer.
- ~RET %~Response~objの~clone ◎ Return clonedResponseObject. ◎ Return clonedResponse.
5.5. `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の被呼出時には、次を走らせ~MUST: ◎ The fetch(input, init) method, must run these steps:
- %p ~LET `新たな~promise$ ◎ Let p be a new promise.
-
%~Request~obj ~LET ( %input, %init ) を引数に[ `Request$I の構築子の初期~値 ]を呼出した結果 ⇒ ただし、例外が投出された場合は ⇒# その例外で %p を`却下する$; ~RET %p ◎ 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 ~ON ]: ◎ If requestObject’s signal’s aborted flag is set, then:
- `~fetchを中止する$( %p, %要請, ~NULL ) ◎ Abort fetch with p, request, and null.
- ~RET %p ◎ 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 次のようにされた,新たな `Response$I ~obj ⇒ `~Headers$Rs ~SET `新たな~Headers$( `immutable^l ) 【 %~Response~obj の`応答$Rsは、後で設定される。】 ◎ Let responseObject be a new Response object and a new associated Headers object whose guard is "immutable".
-
%局所的に中止された ~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を中止する$( %p, %要請, %~Response~obj ) ◎ Abort fetch with p, request, and responseObject.
- 進行中の~fetchを`終了させる$( `中止~flag^i ~SET ~ON ) ◎ Terminate the ongoing fetch with the aborted flag set.
-
この段は`並列的$に走らす: ◎ Run the following in parallel:
%要請 を用いて`~fetch$する — その結果の %応答 に対し: ◎ Fetch request.
-
`応答を処理する$ときは、次の下位手続きを走らす: ◎ To process response for response, run these substeps:
- ~IF[ %局所的に中止された ~EQ ~T ] ⇒ ~RET ◎ If locallyAborted is true, terminate these substeps.
- ~IF[ %応答 の`中止~flag$rs ~EQ ~ON ] ⇒# `~fetchを中止する$( %p, %要請, %~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 で %p を`却下する$; ~RET ◎ If response is a network error, then reject p with a TypeError and terminate these substeps.
- %~Response~obj の`応答$Rs ~SET %応答 ◎ Associate responseObject with response.
- %~Response~obj で %p を`解決する$ ◎ Resolve p with responseObject.
-
`応答の~doneを処理する$ときは、次の下位手続きを走らす: ◎ To process response done for response, run these substeps:
- ~IF[ %局所的に中止された ~EQ ~T ] ⇒ ~RET ◎ If locallyAborted is true, terminate these substeps.
- %~trailer~obj ~LET `新たな~Headers$( `immutable^l ) ◎ Let trailerObject be a new Headers object whose guard is "immutable".
-
~IF[ %応答 の`~trailerは失敗した~flag$rs ~EQ ~ON ]: ◎ If response’s trailer failed flag is set, then:
- %~error ~LET %応答 の`中止~flag$rsに応じて ⇒ ~ON ならば `AbortError$E 例外 / ~OFF ならば `TypeError^E ◎ ↓
- %~error で %~Response~obj の`~trailer~promise$Rsを`却下する$ ◎ If response’s aborted flag is set, reject responseObject’s trailer promise with an "AbortError" DOMException. ◎ Otherwise, reject responseObject’s trailer promise with a TypeError.
- ~RET ◎ Terminate these substeps.
- %~trailer~obj の`~header~list$Hl ~SET %応答 の`~trailer$rs ◎ Associate trailerObject with response’s trailer.
- %~trailer~obj で %~Response~obj の`~trailer~promise$Rsを`解決する$ ◎ Resolve responseObject’s trailer promise with trailerObject.
-
- ~RET %p ◎ 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は`読取可$RSである ] ⇒ %要請 の`本体$rqを %~error で`取消す$RS ◎ 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.
-
%~error で %~Response~obj の`~trailer~promise$Rsを`却下する$ ◎ Reject responseObject’s trailer promise with error.
注記: %~Response~obj の`~trailer~promise$Rs がすでに充足されていた場合、これは何もしない。 ◎ This is a no-op if responseObject’s trailer promise has already fulfilled.
- %応答 ~LET %~Response~obj の`応答$Rs ◎ Let response be responseObject’s response.
- ~IF[ %応答 の`本体$rs ~NEQ ~NULL ]~AND[ %応答 の`本体$rsは`読取可$RSである ] ⇒ %応答 の`本体$rsを %~error で`~errorにする$RS ◎ If response’s body is not null and is readable, then error response’s body with error.
5.6. ~garbage収集
~UAは、進行中の~fetchを — その終了が~scriptを通して観測-可能にならないならば — `終了させ$て~MAY。 ◎ 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)) })
(上の例が観測-可能にならないことは、組込みの[ ~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 の “~WebSocket接続を確立する” ~algoを,新たなものに置換して~Fetchに統合するような仕方で働く — 新たなものは、 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 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, `同期~flag$rq ~SET ~ON, `~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", synchronous flag is set, 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 ~randomに選定された 16 ~byteの値を, base64 に符号化した結果からなる~nonce( `RFC4648$r の 4 節 を見よ) ◎ Let keyValue be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded (see section 4 of [RFC4648]).
例えば,~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値 は `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 `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 ◎ 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.
- %応答 ~LET %要請 を`~fetch$した結果 ◎ Let response be the result of fetching request.
- ~IF[ %応答 は`~network~error$である ]~OR[ %応答 の`~status$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 にて定義される,この~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 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 にて定義される。 `WSP$r ◎ Fail the WebSocket connection and the WebSocket connection is established are defined by The WebSocket Protocol. [WSP]
警告: ~redirectを追わない理由は、~web~browser文脈に深刻な保安~問題をもたらすからである。 そのため、この~handshakeは,一般に制約される。 例えば、ある~hostが ある~pathに~WebSocket~serverを有していたとする。 その~hostが,別の~pathにも `open HTTP redirector^_ を有するようになった時点で、~WebSocket~URLを与え得るような どの~scriptも,その~URLの~hostnameが~~正しいことを検査したとしても,~internet上の~~任意の~hostと通信する(したがって秘匿情報を共有し得る)ように騙すことが可能になる。 ◎ 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 the exclude fragment flag set.
- %入力 から頭部の文字列 `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^smb に限られる。 ◎ 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 string percent decoding of encodedBody.
-
~IF[ %~MIME型 は次の順の並びに合致する ]… ⇒# 任意の文字列 %S, `003B^U `;^smb, 0 個~以上の `0020^U `SPACE^smb, `~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.
背景情報
この節(および その下位節)は規範的でない。 ◎ 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 を拘束する/省略させる手段はある。
◎ 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(`応答$のうち,[ その`~status$rs, または その`内部~応答$の`~status$rs ]が `~redirect~status$であるもの)は、~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$を利用している場合は安全である: ◎ 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.
したがって,言い換えれば、( curl や wget などを利用して)~webに接続している任意の機器からは~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 が利用されないと何が起こるか考える。 ~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`.
しかしながら、ある資源に対し, `Access-Control-Allow-Origin$h を[ `*^bl / 静的な`生成元$ ]に設定する場合、その資源~用の応答~内には,常に — 非`~CORS要請$に対しても,`~CORS要請$と同じく — `Access-Control-Allow-Origin$h を送信するよう,~serverを環境設定して、 `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`.