Fetch

fetch controller controllerに対して、global object globalを与えて、report timingするには:

1. Assert: controllerの report timing stepsがnullでないことを確認する。

2. controllerのreport timing stepsを globalで呼び出す。

fetch controller controllerに対してprocess the next manual redirectするには:

1. Assert: controllerの next manual redirect stepsが nullでないことを確認する。

2. controllerのnext manual redirect stepsを呼び出す。

fetch controller controllerに対してextract full timing infoするには:

1. Assert: controllerのfull timing info がnullでないことを確認する。

2. controllerのfull timing infoを返す。

fetch controller controllerに対して、オプションのerrorでabortするには:

1. controllerのstateを"aborted"に設定する。

2. fallbackErrorを"AbortError" DOMExceptionとする。

3. errorが与えられなければ、fallbackErrorを設定する。

4. serializedErrorをStructuredSerialize(error)とする。 例外が発生したら、それをキャッチしてserializedErrorを StructuredSerialize(fallbackError)とする。

5. controllerのserialized abort reasonに serializedErrorを設定する。

nullまたはRecord abortReasonとrealm realmを与えて、serialized abort reasonをデシリアライズするには:

1. fallbackErrorを"AbortError" DOMExceptionとする。

2. deserializedErrorをfallbackErrorとする。

3. abortReasonがnullでなければ、 deserializedErrorに StructuredDeserialize(abortReason, realm)を設定する。 例外が発生したりundefinedを返したら、deserializedErrorをfallbackErrorに設定する。

4. deserializedErrorを返す。

fetch controller controllerに対してterminateするには、controllerのstateを "terminated"に設定する。

fetch timing info timingInfoを与えてopaque timing infoを作成するには、 timingInfoのstart timeおよび post-redirect start timeが timingInfoのstart timeとなる 新しいfetch timing infoを返す。

アルゴリズムalgorithm、グローバルオブジェクトまたは並列キュー taskDestinationを与えてfetchタスクをキューするには、次の手順を実行する:

1. taskDestinationが並列キューであれば、 enqueue algorithmを taskDestinationへ。

2. それ以外の場合、グローバルタスクをキューする。networking task sourceで taskDestinationおよびalgorithmとともに。

環境設定オブジェクト environment オフラインかどうかを確認するには:

• ユーザーエージェントがインターネット接続がないと仮定する場合、trueを返す。

• environmentのWebDriver BiDi ネットワークがオフラインを返す。

文字列 input、位置変数 position、および省略可能な真偽値extract-value（初期値はfalse）を与えて HTTP引用文字列を収集するには、次の手順を実行する：

1. positionStartをpositionとする。

2. valueを空文字列とする。

3. Assert：inputのpositionの符号位置が U+0022 (") であること。

4. positionを1進める。

5. 無限ループ：

   1. positionからU+0022 (") または U+005C (\) でない符号位置の列を収集し、その結果をvalueに追加する。

   2. positionがinputの末尾を過ぎていれば break。

   3. quoteOrBackslashをinputのpositionの符号位置とする。

   4. positionを1進める。

   5. quoteOrBackslashがU+005C (\) なら：

      1. positionがinputの末尾を過ぎていれば、U+005C (\) をvalueに追加しbreak。

      2. inputのpositionの符号位置をvalueに追加する。

      3. positionを1進める。

   6. それ以外の場合：

      1. Assert：quoteOrBackslashはU+0022 (") であること。

      2. break。

6. extract-valueがtrueなら、valueを返す。

7. inputのpositionStartからpositionまでの符号位置を返す。

ヘッダー名nameと文字列typeを ヘッダーリスト listから与えて、 構造化フィールド値を取得 するには、次の手順を実行します。返り値はnullまたは構造化フィールド値です。

1. Assert: typeは"dictionary"、"list"、"item"のいずれかであること。

2. valueにlistからnameを取得した結果を格納する。

3. valueがnullなら、nullを返す。

4. resultにinput_stringをvalue、header_typeをtypeとしてstructured fieldsをパースした結果を格納する。

5. パースに失敗した場合、nullを返す。

6. resultを返す。

構造化フィールド値の取得は、ヘッダーが存在しない場合と、その値のパースが 構造化フィールド値として失敗した場合を区別しません。これによりウェブプラットフォーム全体で一貫した処理が保証されます。

タプル （ヘッダー名 name、 構造化フィールド値 structuredValue）と ヘッダーリスト listを与えて 構造化フィールド値を設定するには:

1. serializedValueに structured fieldsのシリアライズアルゴリズムをstructuredValueに対して実行した結果を格納する。

2. 設定（name, serializedValue）を listに行う。

構造化フィールド値はHTTPが（将来的に）興味深く効率的な方法でシリアライズできるオブジェクトとして定義されています。現時点では、Fetchはヘッダー値をバイト列としてのみサポートしているため、これらのオブジェクトはシリアライズを通じてのみ ヘッダーリストに設定でき、 パースによってのみヘッダーリストから取得できます。将来的にはこれらがエンドツーエンドでオブジェクトとして保持される可能性があります。[RFC9651]

ヘッダーリスト listがヘッダー名 nameを 含むのは、 listが含むとき、ヘッダーであって、 その名前が バイト大小区別なしでnameと一致する場合です。

ヘッダー名 nameをヘッダーリスト listから 取得するには、次の手順を実行する。返り値はnullまたはヘッダー値。

1. listが含まない場合、nullを返す。

2. list内の、ヘッダーで 名前がバイト大小区別なしでnameと一致するものすべての 値を、0x2C 0x20で区切って順番通りに返す。

ヘッダー名 nameをヘッダーリスト listから 取得・デコード・分割するには、次の手順を実行する。返り値はnullまたは文字列のリスト。

1. valueに、listからnameを取得した結果を格納する。

2. valueがnullなら、nullを返す。

3. valueを取得・デコード・分割した結果を返す。

ヘッダー値 valueを取得・デコード・分割するには、次の手順を実行します。返り値は文字列のリストです。

1. inputにvalueをisomorphic decodeした結果を格納する。

2. positionをinputの位置変数として、先頭位置に設定する。

3. valuesを文字列のリストとして初期化する（初期値 « »）。

4. temporaryValueを空文字列とする。

5. 無限ループ：

   1. positionからU+0022 (") または U+002C (,) でない符号位置の列を収集し、その結果をtemporaryValueに追加する。

      この結果は空文字列でもよい。

   2. positionがinputの末尾を過ぎておらず、かつinputのpositionの符号位置がU+0022 (")なら：

      1. input、positionでHTTP引用文字列を収集し、その結果をtemporaryValueに追加する。

      2. positionがまだ末尾を過ぎていなければcontinue。

   3. temporaryValueの先頭および末尾からすべてのHTTPタブまたはスペースを除去する。

   4. 追加 temporaryValueをvaluesに。

   5. temporaryValueを空文字列に戻す。

   6. positionがinputの末尾を過ぎていれば、valuesを返す。

   7. Assert：inputのpositionの符号位置はU+002C (,)であること。

   8. positionを1だけ進める。

祝福された呼び出し箇所以外では、このアルゴリズムは直接呼び出してはいけません。代わりに取得・デコード・分割を使ってください。

ヘッダー (name, value) をヘッダーリスト listに追加するには：

1. listがnameを含む場合、nameを最初に該当するヘッダーの名前に設定する。

   これによって、既存のヘッダーの名前の大文字・小文字が再利用されます。複数一致する場合、すべてのヘッダーの名前は同一になります。

2. 追加 (name, value) をlistに。

ヘッダー名 nameをヘッダーリスト listから削除するには、 削除 ヘッダーすべて（名前が バイト大小区別なしでnameと一致するもの）をlistから取り除く。

ヘッダー (name, value) をヘッダーリスト listに設定するには：

1. listがnameを含む場合、最初の該当ヘッダーの値をvalueに設定し、他の該当ヘッダーは削除する。

2. それ以外の場合、追加 (name, value) をlistに。

ヘッダー (name, value) をヘッダーリスト listで結合するには：

1. listがnameを含む場合、最初の該当ヘッダーの値の後ろに0x2C 0x20を挟んでvalueを追加する。

2. それ以外の場合、追加 (name, value) をlistに。

結合はXMLHttpRequest および WebSocketプロトコルハンドシェイクで使われます。

名前のリスト headerNamesを与えてソート済み小文字集合へ変換するには、次の手順を実行する。返り値は順序付き集合（ヘッダー名）。

1. headerNamesSetを新しい順序付き集合とする。

2. 各headerNamesのnameについて、追加として、バイト小文字化したnameをheaderNamesSetに加える。

3. 昇順ソートをheaderNamesSetに対してバイト小なりで行い、その結果を返す。

ヘッダーリスト listをソートおよび結合するには、次の手順を実行する。返り値はヘッダーリスト。

1. headersをヘッダーリストとして初期化する。

2. namesに、list内の全名前をソート済み小文字集合へ変換した結果を格納する。

3. 各namesのnameについて：

   1. nameが`set-cookie`なら：

      1. valuesにlist内でnameとバイト大小区別なしで一致するヘッダーすべての値を順番通り格納するリストとする。

      2. 各valuesのvalueについて：

         1. 追加 (name, value) をheadersに。

   2. それ以外の場合：

      1. valueにlistからnameを取得した結果を格納する。

      2. Assert：valueはnullでないこと。

      3. 追加 (name, value) をheadersに。

4. headersを返す。

バイト列 potentialValueを正規化するには、potentialValueから先頭および末尾のHTTP空白バイトを除去する。

ヘッダー（name, value）がCORSセーフリストリクエストヘッダーかどうかを判定するには、次の手順を実行する：

1. valueの長さが128より大きい場合、falseを返す。

2. バイト小文字化したnameで次の分岐を行う：

   `accept`

   valueにCORS-unsafeリクエストヘッダーバイトが含まれていれば、falseを返す。

   `accept-language`

   `content-language`

   valueに、0x30 (0)～0x39 (9)、0x41 (A)～0x5A (Z)、0x61 (a)～0x7A (z)、0x20 (SP)、0x2A (*)、0x2C (,)、0x2D (-)、0x2E (.)、0x3B (;)、0x3D (=) 以外のバイトが含まれていれば、falseを返す。

   `content-type`

   1. valueにCORS-unsafeリクエストヘッダーバイトが含まれていれば、falseを返す。

   2. mimeTypeにMIMEタイプのパースをisomorphic decodeしたvalueに対して行った結果を格納する。

   3. mimeTypeがfailureならfalseを返す。

   4. mimeTypeのessenceが "application/x-www-form-urlencoded", "multipart/form-data", "text/plain" 以外ならfalseを返す。

   ここではMIMEタイプの抽出アルゴリズムは使いません。これは寛容すぎるためで、サーバー側がそのまま実装することを想定していません。

   MIMEタイプの抽出を使った場合、次のリクエストはCORSプリフライトにならず、サーバーの単純なパーサーがリクエストボディをJSONとして扱うかもしれません：

   fetch("https://victim.example/naïve-endpoint", {
     method: "POST",
     headers: [
       ["Content-Type", "application/json"],
       ["Content-Type", "text/plain"]
     ],
     credentials: "include",
     body: JSON.stringify(exerciseForTheReader)
   });
   

   `range`

   1. rangeValueに単一レンジヘッダー値のパースをvalueとfalseで行った結果を格納する。

   2. rangeValueがfailureならfalseを返す。

   3. rangeValue[0]がnullならfalseを返す。

      ウェブブラウザは歴史的に `bytes=-500` のようなレンジは出さないため、このアルゴリズムはそれらをセーフリスト化しません。

   その他

   falseを返す。

3. trueを返す。

`Content-Type`ヘッダーのセーフリストには限定的な例外があり、CORSプロトコルの例外に記載されています。

CORS-unsafeリクエストヘッダーバイトとは、バイトbyteが次のいずれかに該当する場合です：

• byteが0x20未満かつ0x09 HTでない場合

• byteが0x22（"）、0x28（左括弧）、0x29（右括弧）、0x3A（:）、0x3C（<）、0x3E（> ）、0x3F（?）、0x40（@）、0x5B（[）、0x5C（\）、0x5D（]）、0x7B（{）、0x7D（}）、または0x7F DELの場合。

CORS-unsafeリクエストヘッダー名は、ヘッダーリスト headersに対して次の手順で決定します：

1. unsafeNamesを新しいリストとする。

2. potentiallyUnsafeNamesを新しいリストとする。

3. safelistValueSizeを0とする。

4. 各 headers の header について：

   1. headerがCORSセーフリストリクエストヘッダーでなければ、appendでheaderの名前をunsafeNamesに加える。

   2. それ以外の場合、appendでheaderの名前をpotentiallyUnsafeNamesに加え、safelistValueSizeにheaderの値の長さを加算する。

5. safelistValueSizeが1024より大きければ、各 potentiallyUnsafeNamesのnameについて、appendで nameをunsafeNamesに加える。

6. ソート済み小文字集合へ変換したunsafeNamesを返す。

ヘッダー（name, value）がno-CORSセーフリストリクエストヘッダーかどうかを判定するには、次の手順を実行します：

1. nameがno-CORSセーフリストリクエストヘッダー名でなければfalseを返す。

2. （name, value）がCORSセーフリストリクエストヘッダーかどうかを返す。

ヘッダー（name, value）が禁止リクエストヘッダーかどうかは、次の手順でtrueなら該当します：

1. nameが、次のいずれかにバイト大小区別なしで一致すればtrueを返す：

   • `Accept-Charset`
   • `Accept-Encoding`
   • `Access-Control-Request-Headers`
   • `Access-Control-Request-Method`
   • `Connection`
   • `Content-Length`
   • `Cookie`
   • `Cookie2`
   • `Date`
   • `DNT`
   • `Expect`
   • `Host`
   • `Keep-Alive`
   • `Origin`
   • `Referer`
   • `Set-Cookie`
   • `TE`
   • `Trailer`
   • `Transfer-Encoding`
   • `Upgrade`
   • `Via`

   該当すればtrueを返す。

2. nameをバイト小文字化し、`proxy-`または`sec-`で始まる場合、trueを返す。

3. nameが、次のいずれかにバイト大小区別なしで一致すれば：

   • `X-HTTP-Method`
   • `X-HTTP-Method-Override`
   • `X-Method-Override`

   その場合：

   1. parsedValuesに取得・デコード・分割したvalueの結果を格納する。

   2. 各parsedValuesのmethodについて、 そのisomorphic encodeが禁止メソッドであればtrueを返す。

4. falseを返す。

ヘッダー headerに対してヘッダー値を抽出するには次の手順を実行します：

1. headerの値を、そのheaderの名前に該当するABNFでパースして失敗したらfailureを返す。

2. headerの値を、そのheaderの名前に該当するABNFでパースした結果の1つ以上の値を返す。

ヘッダー名 nameとヘッダーリスト listを与えてヘッダーリスト値を抽出するには次の手順を実行します：

1. listがnameを含まない場合、nullを返す。

2. nameに該当するABNFが単一のヘッダーしか許可しない場合、かつlistが複数含む場合はfailureを返す。

   異なるエラー処理が必要な場合は、先に必要なヘッダーを抽出してください。

3. valuesを空のリストとする。

4. listがnameのヘッダーを含む各headerについて：

   1. extractにheaderからヘッダー値を抽出した結果を格納する。

   2. extractがfailureならfailureを返す。

   3. extract内の各値を順番にvaluesへ追加する。

5. valuesを返す。

整数rangeStart、整数rangeEnd、整数fullLengthを与えてコンテンツレンジを構築するには、次の手順を実行します：

1. contentRangeを`bytes `とする。

2. rangeStartを直列化し、isomorphic encodeしてcontentRangeに追加する。

3. 0x2D (-) をcontentRangeに追加する。

4. rangeEndを直列化し、isomorphic encodeしてcontentRangeに追加する。

5. 0x2F (/) をcontentRangeに追加する。

6. fullLengthを直列化し、isomorphic encodeしてcontentRangeに追加する。

7. contentRangeを返す。

バイト列 valueと真偽値allowWhitespaceを与えて単一レンジヘッダー値のパースを行うには、次の手順を実行します：

1. dataにvalueをisomorphic decodeした結果を格納する。

2. dataが"bytes"で始まらない場合、failureを返す。

3. positionをdataの5番目の符号位置を指す位置変数として初期化する。

4. allowWhitespaceがtrueなら、HTTPタブまたはスペースをdataのpositionから収集する。

5. positionのdataにおける符号位置がU+003D (=)でなければfailureを返す。

6. positionを1進める。

7. allowWhitespaceがtrueなら、HTTPタブまたはスペースをdataのpositionから収集する。

8. rangeStartにdataのpositionからASCII数字の列を収集した結果を格納する。

9. rangeStartValueにrangeStartが空でなければ10進数として解釈した値を、空ならnullを格納する。

10. allowWhitespaceがtrueなら、HTTPタブまたはスペースをdataのpositionから収集する。

11. positionのdataにおける符号位置がU+002D (-)でなければfailureを返す。

12. positionを1進める。

13. allowWhitespaceがtrueなら、HTTPタブまたはスペースをdataのpositionから収集する。

14. rangeEndにdataのpositionからASCII数字の列を収集した結果を格納する。

15. rangeEndValueにrangeEndが空でなければ10進数として解釈した値を、空ならnullを格納する。

16. positionがdataの末尾を過ぎていなければfailureを返す。

17. rangeEndValueとrangeStartValueが両方nullならfailureを返す。

18. rangeStartValueとrangeEndValueが数値で、rangeStartValueがrangeEndValueより大きければfailureを返す。

19. (rangeStartValue, rangeEndValue)を返す。

    rangeのendまたはstartは省略可能であり、`bytes=0-`や`bytes=-500`も有効なレンジです。

単一レンジヘッダー値のパースは許可されるレンジヘッダー値の一部でしか成功しませんが、ユーザーエージェントがメディアやダウンロード再開時に使用する最も一般的な形式です。この形式のレンジヘッダー値はRangeヘッダーを追加で設定できます。

環境設定オブジェクト environmentの 環境のデフォルト `User-Agent` 値 を取得するには、次の手順に従う：

1. userAgent を WebDriver BiDi エミュレートされた User-Agent（environment 用）として取得する。

2. userAgent が非 null であれば、userAgent を isomorphic encode されたものとして返す。

3. デフォルトの `User-Agent` 値 を返す。

ボディ bodyを複製するには、次の手順を実行します：

1. « out1, out2 »をbodyのストリームに対してteeした結果とする。

2. bodyのストリームをout1に設定する。

3. 他のメンバーはbodyからコピーし、ボディでstreamがout2のものを返す。

バイト列 bytesをボディとして取得するには、安全に抽出したbytesのボディを返す。

ボディ bodyを逐次的に読み込むには、アルゴリズムprocessBodyChunk、アルゴリズムprocessEndOfBody、アルゴリズムprocessBodyError、および省略可能なnull/並列キューまたはグローバルオブジェクト taskDestination（デフォルトnull）を与えて、次の手順を実行します。 processBodyChunkはバイト列を受け取るアルゴリズム、processEndOfBodyは引数なしアルゴリズム、processBodyErrorは例外を受け取るアルゴリズムでなければなりません。

1. taskDestinationがnullなら、新しい並列キューの開始の結果をtaskDestinationに設定する。

2. readerにbodyのストリームに対してリーダーの取得を実行した結果を格納する。

   この操作で例外はスローされません。

3. 逐次読み込みループをreader、taskDestination、processBodyChunk、processEndOfBody、processBodyErrorで実行する。

ReadableStreamDefaultReader オブジェクトreader、並列キューまたはグローバルオブジェクト taskDestination、アルゴリズムprocessBodyChunk、アルゴリズムprocessEndOfBody、アルゴリズムprocessBodyErrorを与えて逐次読み込みループを実行するには：

1. readRequestを次の読取リクエストとする：

   chunk steps（chunkを与えて）

   1. continueAlgorithmをnullとする。

   2. chunkがUint8Array オブジェクトでなければ、continueAlgorithmを「processBodyErrorにTypeErrorを与えて実行する」に設定する。

   3. それ以外の場合：

      1. bytesにchunkのコピーを格納する。

         実装側は可能な限りこのコピーを避ける戦略を推奨します。

      2. continueAlgorithmを次の手順に設定する：

         1. processBodyChunkにbytesを与えて実行する。

         2. 逐次読み込みループをreader、taskDestination、processBodyChunk、processEndOfBody、processBodyErrorで実行する。

   4. fetchタスクをキューでcontinueAlgorithmとtaskDestinationを与えて実行する。

   close steps

   1. fetchタスクをキューでprocessEndOfBodyとtaskDestinationを与えて実行する。

   error steps（eを与えて）

   1. fetchタスクをキューでprocessBodyErrorにeを与え、taskDestinationで実行する。

2. チャンクの読み取りをreaderにreadRequestを与えて実行する。

ボディ bodyを完全に読み込むには、アルゴリズムprocessBody、アルゴリズムprocessBodyError、および省略可能なnull/並列キューまたはグローバルオブジェクト taskDestination（デフォルトnull）を与えて、次の手順を実行します。processBodyはバイト列を受け取るアルゴリズム、processBodyErrorはオプションで例外を受け取るアルゴリズムでなければなりません。

1. taskDestinationがnullなら、新しい並列キューの開始の結果をtaskDestinationに設定する。

2. successStepsをバイト列 bytesを受け取り、 fetchタスクをキューでprocessBodyにbytesを与えtaskDestinationで実行する手順とする。

3. errorStepsを（オプションの例外 exceptionを受け取り） fetchタスクをキューでprocessBodyErrorにexceptionを与えtaskDestinationで実行する手順とする。

4. readerにbodyのストリームに対してリーダーの取得を実行した結果を格納する。例外が発生した場合、errorStepsをその例外で実行し終了する。

5. 全バイトの読み取りをreaderでsuccessStepsとerrorStepsを与えて実行する。

codingsとbytesを与えてコンテンツ符号化の処理を行うには、次の手順を実行します：

1. codingsがサポートされていなければ、bytesを返す。

2. HTTPの説明通りにcodingsでbytesをデコードした結果（エラーでなければ）を返し、デコードに失敗したらfailureを返す。[HTTP]

リクエスト requestの redirect-taintを計算するには、次の手順を実行する。 それらは "same-origin"、"same-site"、または "cross-site" を返す。

1. Assert: requestのoriginは "client" ではない。

2. lastURLをnullとする。

3. taintを "same-origin" とする。

4. requestのURLリストの各urlについて、反復する：

   1. lastURLがnullなら、lastURLをurlに設定し、 continueする。

   2. urlのoriginが、 lastURLのoriginとsame siteではなく、かつrequestのoriginが lastURLのoriginとsame siteでないなら、 "cross-site" を返す。

   3. urlのoriginが、 lastURLのoriginとsame originではなく、かつrequestのoriginが lastURLのoriginとsame originでないなら、 taintを "same-site" に設定する。

   4. lastURLをurlに設定する。

5. taintを返す。

リクエストrequestが与えられたとき、 リクエストオリジンの直列化は、 次の手順を実行することである：

1. Assert: requestのoriginは "client" ではない。

2. requestのredirect-taintが "same-origin" でないなら、 "null" を返す。

3. requestのoriginを、 直列化したものを返す。

リクエスト requestが与えられたとき、 リクエストオリジンのバイト直列化は、 requestを用いてリクエストオリジンを直列化する結果を 同型エンコードしたものを返すことである。

リクエスト requestを 複製するには、次の手順を実行する：

1. newRequestを、requestのコピーとする。ただし、その body およびWebDriver idを除く。

2. newRequestのWebDriver idを、 ランダムUUIDを生成する結果に設定する。[WEBCRYPTO]

3. requestのbodyが非nullなら、newRequestの body を、requestの bodyを複製する結果に設定する。

4. newRequestを返す。

リクエスト requestに、整数firstと、省略可能な整数 lastを用いて、 範囲ヘッダーを追加するには、次の手順を実行する：

1. Assert: lastが与えられていない、またはfirstは last以下である。

2. rangeValueを `bytes=` とする。

3. firstを直列化して同型エンコードし、 その結果をrangeValueに付加する。

4. 0x2D (-) をrangeValueに付加する。

5. lastが与えられているなら、それを直列化して 同型エンコードし、その結果を rangeValueに付加する。

6. (`Range`、 rangeValue) を requestのヘッダーリストに付加する。

範囲ヘッダーは包含的なバイト範囲を表す。 firstが0でlastが500である範囲ヘッダーは、501バイトの範囲である。

複数のレスポンスを1つの論理リソースに結合する機能は、歴史的に セキュリティバグの原因となってきた。部分レスポンスを扱う機能については、セキュリティレビューを求めること。

レスポンス responseが与えられたとき、 報告用にレスポンスURLを直列化するには、次の手順を実行する：

1. Assert: responseのURLリストは 空ではない。

2. urlを、responseのURLリスト[0]のコピーとする。

   これは、リダイレクト先についての情報漏えいを避けるため、 responseのURLではない （CSP報告における同様の考慮事項も参照）。 [CSP]

3. urlが与えられたものとして、ユーザー名を設定する。値は空文字列とする。

4. urlが与えられたものとして、パスワードを設定する。値は空文字列とする。

5. exclude fragmentをtrueに設定して、 urlの直列化を返す。

リクエスト requestが与えられたとき、 Cross-Origin-Embedder-Policyが 資格情報を許可するかどうかを確認するには、次の手順を実行する：

1. Assert: requestのoriginは "client" ではない。

2. requestのmodeが "no-cors" でないなら、trueを返す。

3. requestのclientがnullなら、trueを返す。

4. requestのclientの ポリシーコンテナーの 埋め込みポリシーの値が "credentialless" でないなら、trueを返す。

5. requestのoriginが、 requestの現在のURLのoriginとsame originであり、かつrequestの redirect-taintが "same-origin" でないなら、trueを返す。

6. falseを返す。

fetch params fetchParamsが与えられたとき、 適切なネットワークエラーを作成するには：

1. Assert: fetchParamsはキャンセル済みである。

2. fetchParamsが 中止済みである場合は中止されたネットワークエラーを返し、 そうでない場合はネットワークエラーを返す。

レスポンス responseを 複製するには、次の手順を実行する：

1. responseがフィルター済みレスポンスである場合、 その内部 レスポンスがresponseの 内部レスポンスの複製である、新しい同一の フィルター済みレスポンスを返す。

2. newResponseを、responseのコピーとする。ただし、その bodyを除く。

3. responseのbodyが非nullなら、 newResponseのbodyを、 responseのbodyを 複製する結果に設定する。

4. newResponseを返す。

レスポンス responseの location URLは、nullまたは ASCII文字列 requestFragmentが与えられたとき、次の手順によって返される値である。それらはnull、failure、 またはURLを返す。

1. responseのstatusがリダイレクトステータスでないなら、 nullを返す。

2. locationを、 `Location` とresponseのヘッダー リストが与えられたときに、ヘッダーリスト値を抽出する結果とする。

3. locationがヘッダー値であるなら、 responseの URLを用いて locationをパースする結果にlocationを設定する。

   responseがResponse コンストラクターを通じて構築された場合、 responseのURLはnullである。これは、locationが absolute-URL-with-fragment stringである場合にのみ、 正常にパースされることを意味する。

4. locationがURLであり、そのfragmentがnullであるなら、 locationのfragmentをrequestFragmentに設定する。

   これにより、合成レスポンス（実のところすべてのレスポンス）が、 HTTPによって定義される リダイレクトの処理モデルに従うことが保証される。[HTTP]

5. locationを返す。

location URLアルゴリズムは、この標準および リダイレクトを手動で扱うHTMLのnavigateアルゴリズムにおける リダイレクト処理のためにのみ使用される。[HTML]

潜在的なdestination potentialDestinationを変換するには、次の手順を実行します：

1. potentialDestinationが"fetch"なら空文字列を返す。

2. Assert: potentialDestinationはdestinationであること。

3. potentialDestinationを返す。

ネットワークパーティションキー keyと オリジン originを与えて オリジンを解決するには、次の手順を実行します：

1. originのhostがIPアドレスであれば、 « originのhost » を返す。

2. originのhostのパブリックスフィックスが"localhost"または"localhost."であれば、 « ::1, 127.0.0.1 » を返す。

3. originを1つ以上のIPアドレスの 集合に変換する 実装依存の操作を行う。

   他にも、IPアドレス以外の 接続情報を取得するために他の操作を行うかどうかも 実装依存です。例えば、 originのスキームが HTTP(S)スキームの場合、実装はHTTPS RRのためのDNSクエリを行うかもしれません。[SVCB]

   この操作が成功した場合、IPアドレスの集合および 追加の実装依存情報を返す。

4. failureを返す。

オリジンを解決するの結果はキャッシュしてもよい。キャッシュする場合はkeyをキャッシュキーの一部として用いるべきである。

コネクションタイミング情報のclampおよびcoarsenを行うには、 コネクションタイミング情報 timingInfo、 DOMHighResTimeStamp defaultStartTime、boolean crossOriginIsolatedCapabilityを与えて次の手順を実行する：

1. timingInfoのコネクション開始時刻が defaultStartTimeより小さければ、新しいコネクションタイミング情報を返す（全ての時刻がdefaultStartTime、ALPNネゴシエートプロトコルはtimingInfoの値）。

2. 新しいコネクションタイミング情報を返す（各時刻はcoarsen timeの結果、ALPNネゴシエートプロトコルはtimingInfoの値）。

コネクションを取得するには、 ネットワークパーティションキー key、 URL url、 真偽値 credentials、オプションの 新規コネクション設定 new（デフォルトは"no"）、 オプションの真偽値 requireUnreliable（デフォルトはfalse）、 そしてオプションの WebTransport-ハッシュリスト webTransportHashes（デフォルトは « »）を与え、次の手順を行う：

1. もし new が"no"ならば：

   1. 確認: webTransportHashes が 空であること。

   2. connections を、ユーザーエージェントの コネクションプール内の、 key が key、 origin が urlの originであり、 credentials が credentials である コネクション の集合とする。

   3. もし connections が空でなく、かつ requireUnreliable がfalseならば、 connections のいずれか1つを返す。

   4. もし connections 内に非信頼性トランスポートを サポートできるコネクション（例：HTTP/3）があるなら そのコネクションを返す。

2. proxies を、urlに対し実装依存の方法でプロキシを探索した結果とする。プロキシがない場合、proxies は « "DIRECT" » とする。

   ここで非標準技術（ WPADや PAC）が活用されることがある。 "DIRECT" はこの url へプロキシを使用しないことを意味する。

3. timingInfo を新しい コネクションタイミング情報にする。

4. 各 proxies の proxy について：

   1. timingInfo の ドメインルックアップ開始時刻を 非安全な共有現在時刻で設定。

   2. hosts を « url の origin の host » とする。

   3. もし proxy が "DIRECT" ならば オリジンの解決 を key, url の origin で実行した結果を hosts に設定する。

   4. もし hosts が失敗ならば 次へ。

   5. timingInfo の ドメインルックアップ終了時刻 を 非安全な共有現在時刻 で設定。

   6. connection を、次を実行した結果とする：コネクション作成を key, url の origin, credentials, proxy、 実装依存な host（hostsより）、 timingInfo、requireUnreliable、webTransportHashes を用い、実装依存の回数だけ並列で実行し、1つ以上値が返るまで待ち、実装依存な方法で返ってきた値から1つを選んで返す。他の返り値がコネクションだった場合は閉じてもよい。

      本質的にこれは、実装がproxy が "DIRECT" の場合には オリジン解決の戻り値から IPアドレス を選択し、それらでレースしたり、IPv6優先、タイムアウト時再試行等も許容することを意味する。

   7. もし connection が失敗ならば 次へ。

   8. もし new が"yes-and-dedicated"でなければ 追加で connection をユーザーエージェントのコネクションプールに追加する。

   9. connection を返す。

5. 失敗を返す。

意図的に曖昧にしてある。なぜならコネクション管理には実装依存の微妙な違いが多数あるためだ。記述があることで <link rel=preconnect> の特徴や、 コネクションが credentials をキーにすることが明確になり、 たとえば TLS セッション識別子が credentials false の コネクションと、 true のコネクションで使い回されないことが明確になる。

コネクションを作成するには、 ネットワークパーティションキー key、 オリジン origin、 真偽値 credentials、文字列 proxy、 ホスト host、 コネクションタイミング情報 timingInfo、 真偽値 requireUnreliable、および WebTransport-ハッシュリスト webTransportHashes を与え、次の手順を行う：

1. timingInfo の コネクション開始時刻 を 非安全な共有現在時刻 で設定する。

2. connection を新しい コネクション とし、 keyはkey、 originはorigin、 credentialsはcredentials、 タイミング情報はtimingInfoとする。 コネクションタイミング情報記録を connection に用い、 connection でHTTPコネクションをhostに確立する。proxyやoriginを考慮しつつ、以下の注意点を踏まえる： [HTTP] [HTTP1] [TLS]

   • もし requireUnreliable が true ならば、非信頼性トランスポート（例えばHTTP/3）が可能なコネクションを確立すること。[HTTP3]

   • 非信頼性トランスポートが可能なコネクションを確立する際は、WebTransport用に必要なオプションを有効化する。 HTTP/3の場合、初期のSETTINGSフレームで SETTINGS_ENABLE_WEBTRANSPORT=1、 H3_DATAGRAM=1 を含めること。 [WEBTRANSPORT-HTTP3] [HTTP3-DATAGRAM]

   • もし credentials が false なら、TLSクライアント証明書を送信しない。

   • もし webTransportHashes が空でない場合は、デフォルトの証明書検証アルゴリズムの代わりに サーバ証明書が 独自証明書要件を満たし、 かつ 証明書ハッシュの検証で webTransportHashesが真であるときのみサーバ証明書を有効とみなす。 いずれかの条件を満たさなければ失敗を返す。

   • 接続確立が成功しなかった場合（UDP/TCP/TLSエラー等）は、失敗を返す。

3. timingInfo の ALPN交渉済みプロトコル を connection の ALPN Protocol ID で設定。ただし以下の注意点がある： [RFC7301]

   • プロキシ経由時にトンネル接続が成立した場合はトンネル先のプロトコルのALPN Protocol ID、 それ以外は最初のプロキシへのALPN Protocol ID を使うこと。

   • ユーザーエージェントが実験的または未登録プロトコルを使う場合は、使用したALPN Protocol IDがあればそれを使う。 ALPN を使わなかった場合は実装で説明的な文字列を使ってもよい。

     timingInfo の ALPN交渉済みプロトコル は 実際の交渉方法に関わらず実際に使用するネットワークプロトコルを識別するためのものであり、 ALPNによるネゴシエーションがなくても利用中のプロトコルを示すALPN Protocol IDである。

   IANAは ALPN Protocol IDのリストを管理している。

4. connection を返す。

コネクションタイミング情報記録は、 コネクション connectionを受け取り、 timingInfoをconnectionの タイミング情報として次を満たすこと：

• timingInfoのコネクション終了時刻は、サーバやプロキシへのコネクション確立直後に unsafe shared current timeとする。詳細：

  • 返される時刻には、トランスポートコネクション確立にかかる時間やSOCKS認証等の時間も含めること。TLSハンドシェイクのリソース要求可能になるまでの時間も含めること。

  • TLS False Start利用時は、サーバのFinishedメッセージ受信までの時間は含めないこと。[RFC7918]

  • 早期データでリクエスト送信時は、サーバのServerHello受信までの時間は含めないこと。[RFC8470]

  • リクエスト送信時にハンドシェイク完了を待つ場合は、早期データ利用の他リクエストが同一コネクションであってもTLSハンドシェイク全体を含めること。

  たとえば、ユーザーエージェントがTLS 1.3でHTTP/2コネクションを確立しGETとPOSTを送信した場合、ClientHello送信時刻をt1、GETはearly dataで送信、POSTは安全でないため（[HTTP] 9.2.1）、t2でハンドシェイク完了まで待つと、同一コネクションでもGETはt1、POSTはt2をコネクション終了時刻として報告します。

• セキュアなトランスポートを使う場合、timingInfoのセキュアコネクション開始時刻は、 connectionをセキュア化するハンドシェイク直前の unsafe shared current timeとする。[TLS]

• connectionがHTTP/3コネクションの場合、timingInfoのコネクション開始時刻とセキュアコネクション開始時刻は等しいこと（HTTP/3ではコネクション確立時にセキュアハンドシェイクも同時に行う）。[HTTP3]

コネクションタイミング情報のclampおよびcoarsenアルゴリズムは、再利用コネクションの詳細やタイム値の丸めを保証します。

environment environmentを与え、ネットワークパーティションキーを決定するには、次の手順を実行します：

1. topLevelOriginをenvironmentの トップレベルオリジンとする。

2. topLevelOriginがnullなら、topLevelOriginをenvironmentのトップレベル生成URLのオリジンとする。

3. Assert: topLevelOriginはオリジンである。

4. topLevelSiteをtopLevelOriginを与えてサイト取得の結果とする。

5. secondKeyをnullまたは実装依存の値とする。

   second keyは意図的に曖昧にされています。詳細は今後詰められます。issue #1035参照。

6. (topLevelSite, secondKey)を返す。

ネットワークパーティションキーを決定するには、 リクエスト request を与え：

1. もし request の 予約クライアント が null でなければ、 request の 予約クライアント を与えて ネットワークパーティションキーを決定する の結果を返す。

2. もし request の クライアント が null でなければ、 request の クライアント を与えて ネットワークパーティションキーを決定する の結果を返す。

3. null を返す。

HTTPキャッシュパーティションを決定するには、リクエスト request を与え：

1. key を ネットワークパーティションキーを決定する (request を与える) の結果とする。

2. もし key が null ならば null を返す。

3. key に関連付けられたユニークなHTTPキャッシュを返す。[HTTP-CACHING]

あるリクエスト request について 悪いポートのためブロックされるべきかどうか判定するには：

1. url を request の 現在のURL とする。

2. もし url の スキーム が HTTP(S)スキーム であり、 url の ポート が 悪いポート であれば、blocked を返す。

3. allowed を返す。

2.10. responseをrequestへのレスポンスとしてMIMEタイプのためにブロックすべきか？

次の手順を実行する：

1. mimeTypeを、responseのヘッダーリストからMIMEタイプ抽出した結果とする。

2. mimeTypeがfailureなら、allowedを返す。

3. destinationをrequestのdestinationとする。

4. destinationがスクリプト系で、以下のいずれかが真ならblockedを返す：

   • mimeTypeのエッセンスが"audio/"、"image/"、"video/"で始まる。
   • mimeTypeのエッセンスが"text/csv"である。

5. allowedを返す。

リクエストの `Cookie` ヘッダーを付加する には、 リクエスト request を与え：

1. ユーザーエージェントが request に対して Cookie を無効化している場合、何もせず戻る。

2. sameSite を same-site モード判定 （request を与える）の結果とする。

3. isSecure を、 request の 現在のURL の スキーム が "https" なら true、 そうでなければ false とする。

4. httpOnlyAllowed を true とする。

   これは fetch から呼ばれるため true である。 例として document.cookie の getter から呼ぶ場合などとは対照的である。

5. cookies を cookie取得を isSecure, request の 現在のURL の ホスト, request の 現在のURL の パス, httpOnlyAllowed, sameSite を与えて実行した結果とする。

   クッキーストアはソート済みのクッキーリストを返す

6. もし cookies が 空 なら、何もせず戻る。

7. value を クッキー直列化に cookies を与えて実行した結果とする。

8. 追加 (`Cookie`, value) を request の ヘッダーリスト に追加。

レスポンスの `Set-Cookie` ヘッダーを解析して保存する には、 リクエスト request および レスポンス response を与え：

1. ユーザーエージェントが request に対して Cookie を無効化している場合、何もせず戻る。

2. allowNonHostOnlyCookieForPublicSuffix を false とする。

3. isSecure を、 request の 現在のURL の スキーム が "https" なら true、 そうでなければ false とする。

4. httpOnlyAllowed を true とする。

   これは fetch から呼ばれているため true となる。 例えば document.cookie の getter とは異なる。

5. sameSiteStrictOrLaxAllowed を、 same-site モード判定 （request を与える）の結果が "strict-or-less" なら true、 そうでなければ false とする。

6. 各 response の ヘッダーリスト の header について：

   1. もし header の 名前が バイト大小無視 で `Set-Cookie` に一致しなければ、 次へ。

   2. クッキーの解析と保存 を header の 値、 isSecure、 request の 現在のURL の ホスト、 request の 現在のURL の パス、 httpOnlyAllowed、 allowNonHostOnlyCookieForPublicSuffix、 sameSiteStrictOrLaxAllowed を渡して実行する。

   3. クッキーのガベージコレクト を request の 現在のURL の ホスト で実行する。

   他の場所でも言及されている通り、`Set-Cookie` ヘッダーはまとめて扱えず、 それぞれ個別に処理される。他のどのヘッダーでもこれは許されない。

same-site モードを判定する には、リクエスト request を与え：

1. 確認: request の メソッド が "GET" または "POST" であること。

2. もし request の トップレベルナビゲーションのイニシエータorigin が null ではなく、かつ request の URL の origin と 同一サイトでなければ "unset-or-less" を返す。

3. もし request の メソッド が "GET" で、かつ request の 送信先 が "document" であれば "lax-or-less" を返す。

4. もし request の クライアント の cross-site な祖先を持つかどうか が true ならば、"unset-or-less" を返す。

5. もし request の リダイレクト汚染度 が "cross-site" なら、"unset-or-less" を返す。

6. "strict-or-less" を返す。

「直列化されたCookie既定パス」を得る には、URL url を与え：

1. cloneURL を url のクローンとする。

2. cloneURL の パス を、 Cookie既定パス（cloneURL の パスを用いて） に設定する。

3. cloneURL の URLパス直列化 を返す。

リクエスト `Origin` ヘッダーを追加するには、 リクエスト request を与え、次の手順を実行する：

1. 確認: requestのoriginが "client" でないこと。

2. serializedOrigin を、 request originのバイト直列化 （requestを用いる）の結果とする。

3. requestの response tainting が "cors" であるか、 mode が "websocket" または "webtransport" の場合は、 `Origin`, serializedOrigin をrequestの header listに 追加する。

4. それ以外で request の method が `GET` でも `HEAD` でもない場合は：

   1. request の mode が "cors" でないなら、 request の referrer policy で分岐する：

      "no-referrer"

      serializedOrigin を `null` にする。

      "no-referrer-when-downgrade"

      "strict-origin"

      "strict-origin-when-cross-origin"

      requestの origin が tuple origin であり、 そのschemeが"https"、かつ requestの current URLの schemeが "https" でない場合、 serializedOrigin を `null` にする。

      "same-origin"

      requestの origin が requestの current URL の origin と 同一生成元でなければ serializedOriginを`null`にする。

      その他

      何もしない

   2. 追加 (`Origin`, serializedOrigin) を request の header list に追加する。

リクエストのreferrer policyは、fetcherが自らのオリジンをサーバーと共有することを明示的に選択していない すべてのfetchで考慮される。たとえば、CORSプロトコルを用いる場合などである。

長さを抽出するには、 ヘッダーリスト headersを与えて次の手順を実行する：

1. valuesを、headersから`Content-Length`を取得・デコード・分割した結果とする。

2. valuesがnullならnullを返す。

3. candidateValueをnullとする。

4. 各 values の value について：

   1. candidateValueがnullなら、candidateValueにvalueを設定する。

   2. そうでなければ、valueがcandidateValueと異なれば、failureを返す。

5. candidateValueが空文字列か、コードポイントにASCII数字でないものが含まれていれば、nullを返す。

6. candidateValueを10進数として解釈して返す。

MIMEタイプを抽出するには、 ヘッダーリスト headersを与えて次の手順を実行する。これらはfailureまたはMIMEタイプを返す。

1. charsetをnullとする。

2. essenceをnullとする。

3. mimeTypeをnullとする。

4. valuesを、headersから`Content-Type`を取得・デコード・分割した結果とする。

5. valuesがnullならfailureを返す。

6. 各 values の value について：

   1. temporaryMimeTypeをvalueをMIMEタイプとして構文解析した結果とする。

   2. temporaryMimeTypeがfailure、またはそのエッセンスが"*/*"なら、continue。

   3. mimeTypeにtemporaryMimeTypeを設定する。

   4. mimeTypeのエッセンスがessenceと異なる場合：

      1. charsetをnullに設定する。

      2. mimeTypeのparameters["charset"]が存在すれば、charsetにその値を設定する。

      3. essenceにmimeTypeのエッセンスを設定する。

   5. そうでなければ、mimeTypeのparameters["charset"]が存在せず、かつcharsetがnullでなければ、mimeTypeのparameters["charset"]にcharsetを設定する。

7. mimeTypeがnullならfailureを返す。

8. mimeTypeを返す。

レガシーエンコーディング抽出は、failureまたはMIMEタイプ mimeTypeとエンコーディング fallbackEncodingを与えて次の手順を実行する：

1. mimeTypeがfailureならfallbackEncodingを返す。

2. mimeType["charset"]が存在しなければ、fallbackEncodingを返す。

3. tentativeEncodingをmimeType["charset"]からエンコーディング取得した結果とする。

4. tentativeEncodingがfailureならfallbackEncodingを返す。

5. tentativeEncodingを返す。

ヘッダーリスト list を与え、 nosniffを判定する には次の手順を行う：

1. values を 取得・デコード・分割 (`X-Content-Type-Options`, list) の結果とする。

2. values が null なら false を返す。

3. values[0] が ASCII大文字小文字無視 で "nosniff" と一致するなら true を返す。

4. false を返す。

3.6.1. response を request で nosniff のためブロックするべきか？

次の手順を行う：

1. nosniffを判定する (response の ヘッダーリスト) が false なら allowed を返す。

2. mimeType を MIME Type抽出 (response の ヘッダーリスト) の結果とする。

3. destination を request の 送信先 とする。

4. destination が スクリプト系 で、 mimeType が失敗 または JavaScript MIME type でなければ blocked を返す。

5. destination が "style" で、 mimeType が失敗 または その エッセンス が "text/css" でなければ blocked を返す。

6. allowed を返す。

リクエストの 送信先のうち スクリプト系 または "style" のときのみ考慮される。 悪用問題が想定されるのはこれらのみ。また "image" は実環境の内容と相性が悪かったため対象外。

オリジン origin、環境設定オブジェクト settingsObject、 文字列 destination、レスポンス response、および省略可能な真偽値 forNavigationが与えられたとき、 cross-origin resource policyチェックを実行するには、次の手順を実行する：

1. forNavigationが与えられていない場合は、falseに設定する。

2. embedderPolicyを、settingsObjectの ポリシーコンテナーの 埋め込みポリシーとする。

3. origin、 "unsafe-none"、response、および forNavigationを用いたcross-origin resource policy 内部チェックがblockedを返すなら、blockedを返す。

   この手順が必要なのは、以下でCross-Origin Embedder Policyに 関係しない違反を報告したくないためである。

4. origin、 embedderPolicyのreport only value、response、 およびforNavigationを用いたcross-origin resource policy 内部チェックがblockedを返すなら、 response、settingsObject、destination、およびtrueを用いて cross-origin embedder policy CORP違反レポートをキューに入れる。

5. origin、 embedderPolicyのvalue、response、および forNavigationを用いたcross-origin resource policy 内部チェックがallowedを返すなら、allowedを返す。

6. response、 settingsObject、destination、およびfalseを用いて cross-origin embedder policy CORP違反レポートをキューに入れる。

7. blockedを返す。

HTMLのnavigateアルゴリズムだけが、forNavigationを trueに設定してこのチェックを使用し、それは常に入れ子のナビゲーションに対してである。そうでない場合、 responseは、opaque filtered responseの 内部レスポンスであるか、または レスポンスであり、それは opaque filtered responseの 内部レスポンスになる。[HTML]

オリジン origin、embedder policy value embedderPolicyValue、レスポンス response、および真偽値 forNavigationが与えられたとき、 cross-origin resource policy内部チェックを 実行するには、次の手順を実行する：

1. forNavigationがtrueで、embedderPolicyValueが "unsafe-none" であるなら、allowedを返す。

2. policyを、responseの ヘッダーリストから `Cross-Origin-Resource-Policy`を 取得する結果とする。

   これは、 `Cross-Origin-Resource-Policy: same-site, same-origin` が以下で allowedになることを意味する。embedderPolicyValueが "unsafe-none" である限り、それは何にも一致しないためである。 2つ以上の `Cross-Origin-Resource-Policy` ヘッダーも同じ効果を持つ。

3. policyが `same-origin`、`same-site`、または `cross-origin` のいずれでもないなら、policyをnullに設定する。

4. policyがnullなら、embedderPolicyValueに応じて分岐する：

   "unsafe-none"

   何もしない。

   "credentialless"

   次の場合は、policyを `same-origin` に設定する：

   • responseのrequest-includes-credentials がtrueである、または
   • forNavigationがtrueである。

   "require-corp"

   policyを `same-origin` に設定する。

5. policyに応じて分岐する：

   null

   `cross-origin`

   allowedを返す。

   `same-origin`

   originが、responseのURLの オリジンとsame originであるなら、allowedを返す。

   そうでなければ、blockedを返す。

   `same-site`

   以下のすべてがtrueである場合：

   • originが、 responseの URLのオリジンとスキームを除いてsame siteである

   • originのschemeが "https" である、または responseのURLのschemeが "https" でない

   その場合はallowedを返す。

   そうでなければ、blockedを返す。

   `Cross-Origin-Resource-Policy: same-site` は、 セキュアな転送経由で配信されたレスポンスが、非セキュアな要求元オリジンに一致するとはみなさない。 それらのホストがそれ以外ではsame siteである場合でも同様である。セキュアに転送されたレスポンスは、 セキュアに転送された開始元にのみ一致する。

レスポンス response、環境設定オブジェクト settingsObject、文字列destination、および真偽値reportOnlyが与えられたとき、 cross-origin embedder policy CORP違反レポートをキューに入れるには、次の手順を実行する：

1. endpointを、reportOnlyがtrueならsettingsObjectの ポリシーコンテナーの 埋め込みポリシーの report only reporting endpointとし、そうでなければ settingsObjectのポリシーコンテナーの 埋め込みポリシーの reporting endpointとする。

2. serializedURLを、 responseを用いて 報告用にレスポンスURLを 直列化する結果とする。

3. dispositionを、reportOnlyがtrueなら "reporting" とし、 そうでなければ "enforce" とする。

4. bodyを、次のプロパティを含む新しいオブジェクトとする：

   key	value
   "type"	"corp"
   "blockedURL"	serializedURL
   "destination"	destination
   "disposition"	disposition

5. settingsObjectの グローバルオブジェクトについて、 "coep" レポート種別、endpoint、および bodyが与えられたものとして、 レポートを生成してキューに入れる。[REPORTING]

リクエスト request、省略可能なアルゴリズム processRequestBodyChunkLength、省略可能なアルゴリズム processRequestEndOfBody、 省略可能なアルゴリズム processEarlyHintsResponse、省略可能な アルゴリズム processResponse、省略可能な アルゴリズム processResponseEndOfBody、省略可能なアルゴリズム processResponseConsumeBody、 および省略可能な真偽値 useParallelQueue（既定値 false）が与えられたとき、 以下の手順を実行する。与えられた場合、processRequestBodyChunkLengthは、 送信されたバイト数を表す整数を受け取るアルゴリズムでなければならない。与えられた場合、 processRequestEndOfBodyは引数を受け取らないアルゴリズムでなければならない。与えられた場合、 processEarlyHintsResponseはレスポンスを受け取るアルゴリズムでなければならない。与えられた場合、 processResponseはレスポンスを受け取るアルゴリズムでなければならない。与えられた場合、 processResponseEndOfBodyはレスポンスを受け取るアルゴリズムでなければならない。与えられた場合、 processResponseConsumeBodyはレスポンス およびnull、failure、またはバイト列を受け取るアルゴリズムでなければならない。

ユーザーエージェントは、進行中のfetchを 一時停止するよう求められることがある。 ユーザーエージェントは、その一時停止要求を受け入れても無視してもよい。一時停止されたfetchは 再開できる。ユーザーエージェントは、 進行中のfetchがそのリクエストについてHTTPキャッシュ内のレスポンスを更新している場合、 その一時停止要求を無視すべきである。

requestのキャッシュモードが "no-store" である場合、または レスポンスに `Cache-Control: no-store` ヘッダーが現れる場合、ユーザーエージェントは リクエストについて HTTPキャッシュ内のエントリーを更新しない。[HTTP-CACHING]

1. Assert: requestのmodeは "navigate" である、または processEarlyHintsResponseはnullである。

   early hints（レスポンスであって、そのstatus が103であるもの）の処理は、ナビゲーションについてのみ精査されている。

2. taskDestinationをnullとする。

3. crossOriginIsolatedCapabilityをfalseとする。

4. requestが与えられたものとして、クライアントからリクエストを設定する。

5. requestのclientが非nullなら、次を実行する：

   1. taskDestinationを、requestのclientの グローバルオブジェクトに設定する。

   2. crossOriginIsolatedCapabilityを、requestの clientの cross-origin isolated capabilityに設定する。

6. useParallelQueueがtrueなら、taskDestinationを 新しい並列キューを開始する結果に設定する。

7. timingInfoを、新しいfetch timing infoとする。その start timeおよび post-redirect start timeは、 crossOriginIsolatedCapabilityが与えられたときの 粗化された共有現在時刻であり、 render-blockingは requestの render-blockingに設定される。

8. fetchParamsを、新しいfetch paramsとする。その requestはrequest、 timing infoはtimingInfo、 process request body chunk lengthは processRequestBodyChunkLength、 process request end-of-bodyは processRequestEndOfBody、 process early hints responseは processEarlyHintsResponse、 process responseは processResponse、 process response consume bodyは processResponseConsumeBody、 process response end-of-bodyは processResponseEndOfBody、 task destinationは taskDestination、かつ cross-origin isolated capabilityは crossOriginIsolatedCapabilityである。

9. requestのbodyがバイト 列であるなら、 requestのbodyを、requestのbody as a bodyに設定する。

10. requestを用いて、WebDriver BiDi clone network request body手順を実行する。

11. 次のすべての条件がtrueである場合：

    • requestのURLのschemeが HTTP(S) schemeである

    • requestのmodeが "same-origin"、 "cors"、または "no-cors" である

    • requestのclientがnullでなく、かつ requestの clientのグローバルオブジェクトが Window オブジェクトである

    • requestのmethodが `GET` である

    • requestのunsafe-request flagが設定されていない、または requestのheader listが空である

    その場合：

    1. Assert: requestのoriginは、 requestのclientの originと same origin である。

    2. onPreloadedResponseAvailableを、レスポンス responseが与えられたときに、 次の手順を実行するアルゴリズムとする： fetchParamsの preloaded response candidateをresponseに設定する。

    3. foundPreloadedResourceを、 requestのclientについて、 requestのURL、requestのdestination、 requestのmode、requestの credentials mode、 requestのintegrity metadata、 およびonPreloadedResponseAvailableが与えられたものとして、 preloaded resourceを消費するを呼び出した結果とする。

    4. foundPreloadedResourceがtrueであり、かつfetchParamsの preloaded response candidateがnullであるなら、fetchParamsの preloaded response candidateを "pending" に設定する。

12. requestのheader listが `Accept` を含まないなら：

    1. valueを `*/*` とする。

    2. requestのinitiatorが "prefetch" なら、 valueをdocument `Accept` header valueに設定する。

    3. そうでない場合、ユーザーエージェントは、requestのdestinationに応じて分岐し、 もしあれば、最初に一致する文にvalueを設定すべきである：

       "document"

       "frame"

       "iframe"

       document `Accept` header value

       "image"

       `image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5`

       "json"

       `application/json,*/*;q=0.5`

       "style"

       `text/css,*/*;q=0.1`

       "text"

       `text/plain,*/*;q=0.5`

    4. (`Accept`、 value) を requestのheader listに付加する。

13. requestのheader listが `Accept-Language` を含まず、かつrequestの clientが非nullであるなら：

    1. emulatedLanguageを、 requestのclientについての WebDriver BiDi emulated languageとする。

    2. emulatedLanguageが非nullなら：

       1. encodedEmulatedLanguageを、emulatedLanguageを 同型エンコードしたものとする。

       2. (`Accept-Language`、encodedEmulatedLanguage) を requestの header listに 付加する。

14. requestのheader listが `Accept-Language` を含まないなら、ユーザーエージェントは (`Accept-Language`、適切な ヘッダー値) を requestのheader listに付加すべきである。

15. requestのinternal priorityがnullであるなら、 requestのpriority、initiator、 destination、およびrender-blockingを 実装定義の方法で用いて、 requestの internal priorityを実装定義のオブジェクトに設定する。

    実装定義のオブジェクトには、 HTTP/2用のストリーム重みおよび 依存関係、それが適用されるトランスポート（HTTP/3を含む）におけるExtensible Prioritization Scheme for HTTPで用いられる優先順位、 ならびにHTTP/1 fetchの ディスパッチおよび処理に優先順位を付けるために用いられる同等の情報を含めることができる。[RFC9218]

16. requestがサブリソースリクエストであるなら：

    1. recordを、新しいfetchレコードとする。その requestはrequestであり、controller はfetchParamsのcontrollerである。

    2. recordを、requestの clientのfetch groupの fetch recordsに付加する。

17. fetchParamsが与えられたものとして、main fetchを実行する。

18. fetchParamsのcontrollerを返す。

リクエスト requestが与えられたとき、 クライアントから リクエストを設定するには：

1. requestのtraversable for user promptsが "client" であるなら：

   1. requestのtraversable for user promptsを "no-traversable" に設定する。

   2. requestのclientが非nullなら：

      1. globalを、requestのclientの グローバルオブジェクトとする。

      2. globalがWindow オブジェクトであり、かつglobalの navigableがnullでないなら、 requestの traversable for user promptsを globalの navigableのtraversable navigableに設定する。

2. requestのoriginが "client" であるなら：

   1. Assert: requestのclientは 非nullである。

   2. requestのoriginを、requestの clientのoriginに設定する。

3. requestのpolicy containerが "client" であるなら：

   1. requestのclientが非nullなら、 requestのpolicy containerを、 requestのclientの policy containerの クローンに設定する。[HTML]

   2. そうでない場合、requestのpolicy containerを、新しい policy containerに設定する。

メインフェッチするには、フェッチパラメータfetchParamsとオプションのブール値recursive（デフォルトはfalse）を指定して、以下の手順を実行します：

1. requestにfetchParamsのrequestを設定する。

2. responseをnullとする。

3. requestのlocal-URLs-only flagがセットされていて、かつrequestのcurrent URLがローカルでなければ、responseにネットワークエラーを設定する。

4. Content Security Policy違反をrequestに対して報告する。

5. 必要に応じてrequestを信頼できるURLにアップグレードする。

6. 必要に応じて混在コンテンツrequestを信頼できるURLにアップグレードする。

7. 悪いポートのためrequestをブロックすべきか、 混在コンテンツとしてrequestのフェッチをブロックすべきか、 Content Security Policyによりrequestをブロックすべきか、 整合性ポリシーによりrequestをブロックすべきか がblockedを返した場合、responseにネットワークエラーを設定する。

8. requestのreferrer policyが空文字列であれば、requestのreferrer policyをrequestのpolicy containerのreferrer policyに設定する。

9. requestのreferrerが"no-referrer"でなければ、requestのreferrerをリクエストのreferrerを決定するの結果に設定する。[REFERRER]

   Referrer Policyに記載されている通り、ユーザーエージェントはエンドユーザーに"no-referrer"に上書きする、またはより機微な情報のみを公開するオプションを提供できます。

10. 以下すべての条件を満たす場合、requestのcurrent URLのschemeを"https"に設定する：

    • requestのcurrent URLのschemeが"http"
    • requestのcurrent URLのhostがドメインである
    • requestのcurrent URLのhostのpublic suffixが"localhost"または"localhost."ではない
    • requestのcurrent URLのhostをKnown HSTS Host Domain Name Matchingで照合した結果、includeSubDomains指令付きのスーパー領域一致または一致（includeSubDomains指令の有無問わず）が得られる、もしくはDNS解決でリクエストがsection 9.5のHTTPS RRと一致する場合。[HSTS] [SVCB]

    すべてのDNS操作は通常実装定義であるため、DNS解決にHTTPS RRが含まれているかどうかの判定も実装定義です。DNS操作は伝統的にコネクション取得の試行まで行われないため、ユーザーエージェントはDNS操作を早期に実施したり、ローカルDNSキャッシュを参照したり、フェッチアルゴリズムの後段で判明した場合に論理を巻き戻す必要があるかもしれません。

11. recursiveがfalseであれば、残りの手順を並列で実行する。

12. responseがnullであれば、最初に一致する条件の手順を実行してresponseを設定する：

    fetchParamsのpreloaded response candidateがnullでない

    1. fetchParamsのpreloaded response candidateが"pending"でなくなるまで待つ。

    2. アサート：fetchParamsのpreloaded response candidateがレスポンスである。

    3. fetchParamsのpreloaded response candidateを返す。

    requestのcurrent URLのoriginがrequestのoriginと同一オリジンで、かつrequestのresponse taintingが"basic"である

    requestのcurrent URLのschemeが"data"である

    request の mode が "navigate"、"websocket" または "webtransport" の場合

    1. requestのresponse taintingを"basic"に設定する。

    2. 「scheme-fetch」と fetchParams を指定して、override fetch を実行した結果を返す。

    HTMLは、URL の スキーム が "data" の場合、 そこから作成されるドキュメントおよびワーカーに一意な 不透明オリジン を割り当てます。Service Worker は URL の スキーム が HTTP(S) スキーム である場合のみ作成できます。 [HTML] [SW]

    requestのmodeが"same-origin"である

    ネットワークエラーを返す。

    requestのmodeが"no-cors"である

    1. requestのredirect modeが"follow"でなければネットワークエラーを返す。

    2. requestのresponse taintingを"opaque"に設定する。

    3. 「scheme-fetch」と fetchParams を指定して、override fetch を実行した結果を返す。

    requestのcurrent URLのschemeがHTTP(S)スキームでない

    ネットワークエラーを返す。

    requestのuse-CORS-preflight flagがセットされている

    requestのunsafe-request flagがセットされていて、かつrequestのmethodがCORS安全リストメソッドでない、またはCORS安全でないリクエストヘッダー名がrequestのheader listで空でない

    1. requestのresponse taintingを"cors"に設定する。

    2. corsWithPreflightResponse を、「http-fetch」、fetchParams、および true を指定して override fetch を実行した結果とする。

    3. corsWithPreflightResponseがネットワークエラーであれば、キャッシュエントリをクリアをrequestで実行する。

    4. corsWithPreflightResponseを返す。

    その他

    1. requestのresponse taintingを"cors"に設定する。

    2. 「http-fetch」と fetchParams を指定して、override fetch を実行した結果を返す。

13. recursiveがtrueであれば、responseを返す。

14. responseがネットワークエラーでなく、かつresponseがフィルタ済みレスポンスでなければ、以下を実行する：

    1. requestのresponse taintingが"cors"であれば、以下を実行する：

       1. headerNamesにヘッダーリスト値の抽出を`Access-Control-Expose-Headers`とresponseのheader listで実行した結果を設定する。

       2. requestのcredentials modeが"include"でなく、かつheaderNamesが`*`を含んでいれば、responseのCORS公開ヘッダー名リストにresponseのheader listに含まれるすべての一意なヘッダー名を設定する。

       3. それ以外でheaderNamesがnullまたは失敗でなければ、responseのCORS公開ヘッダー名リストにheaderNamesを設定する。

          headerNamesのうち1つは`*`である場合がありますが、この時点ではヘッダーの名が`*`の場合のみ一致します。

    2. 以下に応じてresponseをresponseを内部レスポンスとするフィルタ済みレスポンスに設定する：

       "basic"

       基本フィルタ済みレスポンス

       "cors"

       CORSフィルタ済みレスポンス

       "opaque"

       不透明フィルタ済みレスポンス

15. internalResponseにresponseを設定する。ただしresponseがネットワークエラーならresponse、それ以外ならresponseの内部レスポンスを設定する。

16. internalResponseのURLリストが空であるなら、 それをrequestのURLリストの クローンに設定する。

    レスポンスのURLリストは 空になり得る。たとえば、 about: URLをfetchするときである。

17. internalResponseのredirect taintを、requestの redirect-taintに設定する。

18. requestがナビゲーションリクエストであるなら、 internalResponseのナビゲーションタイミング許可値 リストを、requestの ナビゲーションタイミング許可値 リストのクローンに設定する。

19. requestのタイミング許可失敗フラグが未設定なら、 internalResponseのタイミング許可通過フラグを設定する。

20. responseがネットワークエラーでなく、次のいずれかが blockedを返すなら

    • internalResponseから requestへのものを混在コンテンツとしてブロックすべきか

    • internalResponseから requestへのものをContent Security Policyによってブロックすべきか

    • internalResponseからrequestへのものをそのMIME タイプによりブロックすべきか

    • internalResponseからrequestへのものをnosniffによりブロックすべきか

    その場合、responseおよびinternalResponseをネットワークエラーに設定する。

21. responseのtypeが "opaque" であり、 internalResponseのstatusがrange statusであり、 internalResponseのrange-requested flagが設定されており、 requestのheader listが `Range` を含まないなら、 responseおよびinternalResponseを ネットワークエラーに設定する。

    従来、APIは範囲が要求されていない場合でも範囲レスポンスを受け入れる。これは、 以前の範囲リクエストからの部分レスポンスまたは範囲を満たせないレスポンスが、 範囲リクエストを行っていないAPIに提供されることを防ぐ。

    さらなる詳細

    上記の手順は、次の攻撃を防ぐ：

    media要素が、クロスオリジンHTMLリソースの範囲を要求するために用いられる。これは 無効なメディアであるが、レスポンスのクローンへの参照をサービスワーカー内に保持できる。これは 後でscript要素のfetchへのレスポンスとして使用できる。部分レスポンスが有効な JavaScriptである場合（リソース全体はそうでなくても）、それを実行するとプライベート データが漏えいすることになる。

22. responseがネットワークエラーでなく、かつ requestのmethodが `HEAD` または `CONNECT` であるか、またはinternalResponseの statusがnull body statusであるなら、 internalResponseのbodyを nullに設定し、それに向けたエンキューを（もしあれば）すべて無視する。

    これは、HTTPに違反するサーバーに対するエラー処理を標準化する。

23. requestのintegrity metadataが空文字列でないなら、 次を実行する：

    1. processBodyErrorを次の手順とする：fetchParamsおよび ネットワークエラーが与えられたものとして、fetch response handoverを実行する。

    2. responseのbodyがnullであるなら、 processBodyErrorを実行し、これらの手順を中止する。

    3. bytesが与えられたときのprocessBodyを、次の手順とする：

       1. bytesがrequestの integrity metadataに 一致しないなら、 processBodyErrorを実行し、これらの手順を中止する。[SRI]

       2. responseのbodyを、bytes as a bodyに設定する。

       3. fetchParamsおよびresponseが与えられたものとして、fetch response handoverを実行する。

    4. responseのbodyを、 processBodyおよびprocessBodyErrorが与えられたものとして完全に 読む。

24. そうでない場合、fetchParamsおよび responseが与えられたものとして、fetch response handoverを実行する。

フェッチレスポンス引き渡しは、フェッチパラメータfetchParamsとレスポンスresponseを指定して、以下の手順を実行します：

1. timingInfoにfetchParamsのタイミング情報を設定する。

2. responseがネットワークエラーでなく、かつfetchParamsのrequestのclientがセキュアコンテキストなら、timingInfoのserver-timing headersにresponseの内部レスポンスのヘッダーリストから`Server-Timing`を取得・デコード・分割した結果を設定する。

   responseの内部レスポンスを用いるのは安全です。`Server-Timing`ヘッダー情報の公開は`Timing-Allow-Origin`ヘッダーによって制御されます。

   ユーザーエージェントは非セキュアコンテキストのリクエストにも`Server-Timing`ヘッダーを公開する場合があります。

3. fetchParamsのrequestのdestinationが"document"であれば、fetchParamsのcontrollerのfull timing infoにfetchParamsのタイミング情報を設定する。

4. processResponseEndOfBodyに以下の手順を設定する：

   1. unsafeEndTimeにunsafe shared current timeを設定する。

   2. fetchParamsのcontrollerのreport timing stepsに、グローバルオブジェクトglobalを受け取る手順として以下を設定する：

      1. fetchParamsのrequestのURLのschemeがHTTP(S)スキームでなければreturnする。

      2. timingInfoのend timeにrelative high resolution time（unsafeEndTime, globalを指定）で設定する。

      3. cacheStateにresponseのcache stateを設定する。

      4. bodyInfoにresponseのbody infoを設定する。

      5. responseのtiming allow passed flagが未設定なら、timingInfoに不透明タイミング情報の作成（timingInfoを指定）の結果を設定し、cacheStateを空文字列に設定する。

         これはresponseがネットワークエラーの場合を含みます。

      6. responseStatusを0に設定する。

      7. fetchParamsのrequestのmodeが"navigate"でない、またはresponseのredirect taintが"same-origin"であれば：

         1. responseStatusにresponseのstatusを設定する。

         2. mimeTypeにMIMEタイプの抽出（responseのheader listを指定）の結果を設定する。

         3. mimeTypeが失敗でなければ、bodyInfoのcontent typeにサポートされているMIMEタイプの最小化（mimeType）の結果を設定する。

      8. fetchParamsのrequestのinitiator typeがnullでなければ、mark resource timing（timingInfo, fetchParamsのrequestのURL, fetchParamsのrequestのinitiator type, global, cacheState, bodyInfo, responseStatus)を実行する。

   3. processResponseEndOfBodyTaskに以下の手順を設定する：

      1. fetchParamsのrequestのdone flagを設定する。

      2. fetchParamsのprocess response end-of-bodyがnullでなければ、fetchParamsのprocess response end-of-body（response）を実行する。

      3. fetchParamsのrequestのinitiator typeがnullでなく、かつfetchParamsのrequestのclientのグローバルオブジェクトがfetchParamsのtask destinationであれば、fetchParamsのcontrollerのreport timing steps（fetchParamsのrequestのclientのグローバルオブジェクト）を実行する。

   4. フェッチタスクをキューし、processResponseEndOfBodyTaskをfetchParamsのtask destinationで実行する。

5. fetchParamsのprocess responseがnullでなければ、フェッチタスクをキューし、fetchParamsのprocess response（response）をfetchParamsのtask destinationで実行する。

6. internalResponseにresponseを設定する。ただしresponseがネットワークエラーならresponse、それ以外ならresponseの内部レスポンスを設定する。

7. response がネットワークエラーであれば、 request を引数に WebDriver BiDi フェッチエラーの手順を実行する。そうでなければ、 request と response を引数に WebDriver BiDi レスポンス完了の手順を実行する。

8. internalResponseのbodyがnullなら、processResponseEndOfBodyを実行する。

9. それ以外の場合：

   1. transformStreamに新しいTransformStreamを設定する。

   2. identityTransformAlgorithmに、chunkを受け取ったときtransformStreamにchunkをenqueueするアルゴリズムを設定する。

   3. transformStreamのセットアップを行い、transformAlgorithmをidentityTransformAlgorithmに、flushAlgorithmをprocessResponseEndOfBodyに設定する。

   4. internalResponseのbodyのstreamに、internalResponseのbodyのstreamをpipe throughした結果をtransformStreamで設定する。

   このTransformStreamは、ストリームの終端到達時の通知目的で必要です。それ以外は恒等変換ストリームです。

10. fetchParamsのprocess response consume bodyがnullでなければ、以下を実行する：

    1. processBodyにnullOrBytesを受け取ったときfetchParamsのprocess response consume body（response, nullOrBytes）を実行する手順を設定する。

    2. processBodyErrorにfetchParamsのprocess response consume body（response, failure）を実行する手順を設定する。

    3. internalResponseのbodyがnullなら、フェッチタスクをキューし、processBody（null）をfetchParamsのtask destinationで実行する。

    4. それ以外の場合、完全に読み取るをinternalResponseのbodyに対してprocessBody, processBodyError, fetchParamsのtask destinationで実行する。

オーバーライドフェッチは、「scheme-fetch」または「http-fetch」の type、fetch params fetchParams、さらにオプションの boolean makeCORSPreflight（デフォルトは false）を受け取る：

1. request を fetchParams の request とする。

2. response を request に対して 要求のオーバーライド可能なレスポンス を実行した結果とする。

3. response が null でなければ、response を返す。

4. type に応じて以下を実行する：

   "scheme fetch"

   response を スキームフェッチ を fetchParams で実行した結果とする。

   "HTTP fetch"

   response を HTTPフェッチ を fetchParams と makeCORSPreflight で実行した結果とする。

5. response を返す。

リクエストに対してレスポンスを潜在的に上書きする アルゴリズムは、リクエスト requestを受け取り、レスポンスまたはnullのいずれかを返す。その挙動は 実装定義であり、ユーザーエージェントが レスポンスを直接返すことでリクエストに 介入すること、またはnullを返すことでリクエストの続行を許可することを可能にする。

既定では、このアルゴリズムは次の自明な実装を持つ：

1. nullを返す。

スキームフェッチは、fetch params fetchParams を受け取る：

1. fetchParams が キャンセル済みの場合、fetchParamsに対して 適切なネットワークエラー を返す。

2. request を fetchParams の request とする。

3. request の current URL の scheme に応じて以下の手順を実行する：

   "about"

   request の current URL の path が "blank" の場合、response を新規作成し、 status message を `OK`、 header list を « (`Content-Type`, `text/html;charset=utf-8`) »、 body を空のバイト列 本文として設定して返す。

   URL（例："about:config"）は ナビゲーション時に処理され、 fetchの文脈では ネットワークエラー となる。

   "blob"

   1. blobURLEntry を、request の current URL の blob URL entry とする。

   2. もし request の method が `GET` でない、または blobURLEntry が null であるなら、network error を返す。 [FILEAPI]

      `GET` method の制約は、相互運用性以外に有用な目的を持たない。

   3. requestEnvironment を、request を与えて 環境を決定した結果とする。

   4. isTopLevelSelfFetch を false とする。

   5. もし request の client が non-null なら:

      1. global を、request の client の global object とする。

      2. 次の条件がすべて真なら:

         • global は Window オブジェクトである;

         • global の navigable が null ではない;

         • global の navigable の parent が null である; そして

         • requestEnvironment の creation URL が equals であり、 request の current URL に等しい、

         その場合、isTopLevelSelfFetch を true に設定する。

   6. stringOrEnvironment を次の手順の結果とする:

      1. もし request の destination が "document" なら、 "top-level-navigation" を返す。

      2. もし isTopLevelSelfFetch が true なら、 "top-level-self-fetch" を返す。

      3. requestEnvironment を返す。

   7. blob を、blobURLEntry と stringOrEnvironment を与えて blob オブジェクトを取得した結果とする。

   8. もし blob が Blob オブジェクトでないなら、network error を返す。

   9. response を新しい response とする。

   10. fullLength を blob の size とする。

   11. serializedFullLength を、fullLength を serialized および isomorphic encoded したものとする。

   12. type を blob の type とする。

   13. もし request の header list が 含まない 場合、 `Range` を:

       1. bodyWithType を、安全に抽出して得た blob の結果とする。

       2. response の status message を `OK` に設定する。

       3. response の body を、 bodyWithType の body に設定する。

       4. response の header list を « (`Content-Length`, serializedFullLength), (`Content-Type`, type) » に設定する。

   14. それ以外の場合:

       1. response の range-requested flag を設定する。

       2. rangeHeader を、取得した結果、すなわち request の header list からの `Range` とする。

       3. rangeValue を、単一の Range ヘッダー値を解析 した結果とし、rangeHeader と true を与える。

       4. もし rangeValue が failure なら、network error を返す。

       5. (rangeStart, rangeEnd) を rangeValue とする。

       6. もし rangeStart が null なら:

          1. rangeStart を fullLength − rangeEnd に設定する。

          2. rangeEnd を rangeStart + rangeEnd − 1 に設定する。

       7. それ以外の場合:

          1. もし rangeStart が fullLength 以上なら、 network error を返す。

          2. もし rangeEnd が null、または rangeEnd が fullLength 以上なら、rangeEnd を fullLength − 1 に設定する。

       8. slicedBlob を、slice blob を呼び出した結果とし、 blob, rangeStart, rangeEnd + 1, および type を与える。

          Range ヘッダーは包含的なバイト範囲を表す一方で、slice blob アルゴリズムの入力範囲はそうではない。slice blob アルゴリズムを使用するためには、 rangeEnd をインクリメントする必要がある。

       9. slicedBodyWithType を、 安全に抽出した slicedBlob の結果とする。

       10. response の body を、 slicedBodyWithType の body に設定する。

       11. serializedSlicedLength を、slicedBlob の size を serialized および isomorphic encoded したものとする。

       12. contentRange を、content range を構築した結果とし、 rangeStart, rangeEnd, および fullLength を与える。

       13. response の status を 206 に設定する。

       14. response の status message を `Partial Content` に設定する。

       15. response の header list を « (`Content-Length`, serializedSlicedLength), (`Content-Type`, type), (`Content-Range`, contentRange) » に設定する。

   15. response を返す。

   "data"

   1. dataURLStruct を、request の data: URL プロセッサ を current URL に対して実行した結果とする。

   2. もし dataURLStruct が failure なら、network error を返す。

   3. mimeType を、dataURLStruct の MIME type を 直列化したものとする。

   4. 新しい response を返す。その status message は `OK`、header list は « (`Content-Type`, mimeType) »、そして body は dataURLStruct の body を 本文として 用いたものである。

   "file"

   現時点では不本意ながら、file: URL は読者への演習問題として残されている。

   判断に迷う場合は、network error を返すこと。

   HTTP(S) スキーム

   fetchParams を与えて HTTP fetch を実行した結果を返す。

4. network error を返す。