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のsame siteでなければ、"cross-site"を返す。

   3. urlのoriginがlastURLのoriginとsame originでなく、かつrequestのoriginもlastURLのsame originでなければ、taintを"same-site"とする。

   4. lastURLをurlとする。

5. taintを返す。

request requestに対してリクエストoriginの直列化を行うには、次の手順を実行します：

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

2. requestのredirect-taintが"same-origin"でなければ、"null"を返す。

3. requestのoriginを直列化して返す。

request requestに対してリクエストoriginのバイト直列化を行うには、リクエストoriginの直列化の結果をisomorphic encodeしたものを返す。

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

1. newRequestをrequestのコピー（ただしbodyは除く）とする。

2. requestのbodyがnullでなければ、newRequestのbodyに複製したrequestのbodyを設定する。

3. newRequestを返す。

リクエスト requestに整数first、オプションで整数lastを与えてRangeヘッダーを追加するには、次の手順を実行します：

1. Assert: lastが与えられていないか、firstがlast以下であること。

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

3. 直列化し、isomorphic encodeしたfirstをrangeValueに追加する。

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

5. lastが与えられていれば、それを直列化してisomorphic encodeした結果をrangeValueに追加する。

6. 追加（`Range`、rangeValue）をrequestのヘッダーリストに行う。

Rangeヘッダーはバイト範囲（両端を含む）を表します。たとえば、firstが0、lastが500の場合、501バイトの範囲になります。

複数のレスポンスを1つの論理リソースに結合する機能は、歴史的にセキュリティバグの原因となってきました。部分レスポンスを扱う機能を設計する場合は、必ずセキュリティレビューを受けてください。

response responseに対して報告用レスポンスURLの直列化を行うには、次の手順を実行します：

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

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

   これはresponseのURLではありません。リダイレクト先の情報漏えいを防ぐためです（CSP報告の同様の考慮事項も参照）。[CSP]

3. ユーザー名を空文字列に設定する（urlに対して）。

4. パスワードを空文字列に設定する（urlに対して）。

5. 直列化したurlを、フラグメント除外をtrueにして返す。

request requestに対してCross-Origin-Embedder-Policyが認証情報を許可するか確認するには、次の手順を実行します：

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

2. requestのmodeが"no-cors"でなければtrueを返す。

3. requestのclientがnullであればtrueを返す。

4. requestのclientのポリシーコンテナのembedder policyの値が"credentialless"でなければtrueを返す。

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

6. falseを返す。

fetch params fetchParamsを与えて適切なネットワークエラーを作るには：

1. Assert: fetchParamsがcanceledであること。

2. fetchParamsがabortedなら中断されたネットワークエラーを、それ以外ならネットワークエラーを返す。

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

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

2. newResponseをresponseのコピー（ただしボディを除く）とする。

3. responseのボディがnullでなければ、newResponseのボディに複製したresponseのボディを設定する。

4. newResponseを返す。

レスポンス responseの location URLは、 nullまたはASCII文字列 requestFragmentを与えて、 次の手順で決定されます。返り値はnull・failure・またはURLです。

1. responseのstatusが リダイレクトステータスでなければnullを返す。

2. locationを ヘッダーリスト値を抽出（`Location`・responseのヘッダーリスト）の結果とする。

3. locationがヘッダー値なら、 locationをパース（location・responseのURL）の結果に置き換える。

   responseがResponseコンストラクターで生成された場合、 responseのURLはnullとなるため、 locationは絶対URL+フラグメント文字列でなければパースに成功しません。

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、 boolean credentials、 任意の新規コネクション設定 new（初期値"no"）、 任意のboolean requireUnreliable（初期値false）を与え、次の手順を実行する：

1. newが"no"なら：

   1. connectionsをユーザーエージェントのコネクションプール内の、 キーがkey、 オリジンがurlのオリジン、 認証情報がcredentialsであるコネクションの集合とする。

   2. connectionsが空でなく、requireUnreliableがfalseなら、その中の1つを返す。

   3. connections内に、例えばHTTP/3など、unreliable transport対応のコネクションがあれば、それを返す。

2. proxiesを実装依存の方法でurlのプロキシとして探索した結果とする。なければ« "DIRECT" »とする。

   ここで非標準技術（WPADやPAC）が使われる可能性があります。"DIRECT"は、このurlでプロキシを使わないことを意味します。

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

4. 各proxiesのproxyについて：

   1. timingInfoのドメインルックアップ開始時刻 をunsafe shared current timeに設定する。

   2. hostsを« urlのオリジンのhost »とする。

   3. proxyが"DIRECT"なら、hostsをkeyとurlのオリジンを与えてオリジンを解決するの結果に設定する。

   4. hostsがfailureなら、continue。

   5. timingInfoのドメインルックアップ終了時刻を unsafe shared current timeに設定する。

   6. connectionを、以下の手順で得られた結果とする：コネクション作成に、key、urlのオリジン、credentials、proxy、hostsから実装依存で選択したhost、timingInfo、requireUnreliableを与え、実装依存の回数だけ並列で実行し、少なくとも1つの値を待つ。実装依存で返す値を選び、それを返す。他の値（コネクション）は閉じてよい。

      本質的には、オリジンを解決する（proxyが"DIRECT"の場合）から返された複数のIPアドレスを競わせたり、IPv6優先したり、タイムアウトで再試行したりできることを意味します。

   7. connectionがfailureなら、continue。

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

   9. connectionを返す。

5. failureを返す。

コネクション管理には多くの微妙な点があるため、詳細は実装者の裁量に任せています。これを記述することで、<link rel=preconnect>やコネクションが認証情報でキーされることを明確にできます。例えば、TLSセッションIDは認証情報がfalseのコネクションとtrueのコネクション間で再利用されません。

コネクション作成は、 ネットワークパーティションキー key、 オリジン origin、 boolean credentials、string proxy、 host host、 コネクションタイミング情報 timingInfo、 boolean requireUnreliableを与え、次の手順を実行する：

1. timingInfoのコネクション開始時刻を unsafe shared current timeに設定する。

2. connectionを新しいコネクションとし、 キーにkey、 オリジンにorigin、 認証情報にcredentials、 タイミング情報にtimingInfoを持たせる。 コネクションタイミング情報記録を行い、 connectionを使ってhostにHTTPコネクションを確立する（proxy、originを考慮）。以下の注意点あり： [HTTP] [HTTP1] [TLS]

   • requireUnreliableがtrueなら、unreliable transport対応（例：HTTP/3）のコネクションを確立する。[HTTP3]

   • unreliable transport対応コネクションの場合、WebTransport用オプション（HTTP/3の場合、SETTINGS_ENABLE_WEBTRANSPORTを1・H3_DATAGRAMを1で初期SETTINGSフレームに含める）を有効化する。[WEBTRANSPORT-HTTP3] [HTTP3-DATAGRAM]

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

   • コネクション確立に失敗した場合（UDP/TCP/TLSエラー等）は、failureを返す。

3. timingInfoのALPNネゴシエートプロトコルを connectionのALPN Protocol IDに設定する。以下の注意点あり：[RFC7301]

   • プロキシ利用時は、トンネルが確立されていればそのプロトコルのALPN Protocol ID、そうでなければ最初のプロキシへのALPN Protocol IDとする。

   • 実験的・非登録プロトコルの場合、利用したALPN Protocol ID（あれば）を使う。ALPNを使っていない場合は別の説明的な文字列でもよい。

     timingInfoのALPNネゴシエートプロトコルは、実際のネゴシエーション方法に関わらず利用中のネットワークプロトコルを識別するためのものです。

   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 requestを与え、ネットワークパーティションキーを決定するには、次の手順を実行します：

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

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

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をrequestに対してsame-siteモードを決定するの結果とする。

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

4. httpOnlyAllowedをtrueとする。

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

5. cookiesをisSecure、requestの現在のURLのホスト、requestの現在のURLのパス、httpOnlyAllowed、sameSiteを与えてCookie取得の結果とする。

   Cookieストアは順序付きのCookieリストを返す。

6. cookiesが空であれば、何もせず戻る。

7. valueをcookiesを与えてCookie直列化の結果とする。

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を、requestに対してsame-siteモードを決定するの結果が"strict-or-less"ならtrue、そうでなければfalseとする。

6. 各 header をresponseのヘッダーリストから順に処理する：

   1. headerの名前がSet-Cookieとバイト単位で大文字小文字を区別せず一致しなければ、continue。

   2. Cookieの解析および保存をheaderの値、isSecure、requestの現在のURLのホスト、requestの現在のURLのパス、httpOnlyAllowed、allowNonHostOnlyCookieForPublicSuffix、sameSiteStrictOrLaxAllowedを与えて実行する。

   3. Cookieのガベージコレクトをrequestの現在のURLのホストを与えて実行する。

   他の場所でも指摘されているとおり、`Set-Cookie`ヘッダーは結合できず、各出現ごとに個別に処理される。他のヘッダーではこれは許可されない。

same-siteモードを決定するには、リクエスト requestを与えて次の手順を実行する：

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

2. requestのトップレベルナビゲーションイニシエータオリジンがnullでなく、かつrequestのURLのオリジンとsame siteでなければ、"unset-or-less"を返す。

3. requestのメソッドが"GET"かつ requestのdestinationが"document"なら、"lax-or-less"を返す。

4. requestのclientのcross-site ancestorを持つがtrueなら、"unset-or-less"を返す。

5. requestのredirect-taintが"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. Assert: requestのoriginは"client"でない。

2. serializedOriginを、requestを与えてリクエストオリジンのバイト列シリアライズの結果とする。

3. もし request のresponse tainting が "cors" であるか、 または request のmode が "websocket" または "webtransport" のいずれかである場合、 append（`Origin`、serializedOrigin）を request のheader listに行う。

4. さもなければ、requestのメソッドが`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がタプルオリジンで、 そのschemeが"https"、かつrequestの現在のURLのschemeが"https"でなければ serializedOriginを`null`に設定する。

      "same-origin"

      requestのoriginが requestの現在のURLのオリジンと 同一オリジンでなければ serializedOriginを`null`に設定する。

      その他

      何もしない。

   2. 追加 (`Origin`, serializedOrigin) を request の ヘッダーリスト に追加する。

リクエストのreferrer policyは、 フェッチャーがサーバーとオリジンを共有することを明示的に選択していないすべての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を返す。

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

1. valuesをlistから`X-Content-Type-Options`を取得・デコード・分割した結果とする。

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

3. values[0]が"nosniff"とASCII大文字・小文字を区別せず一致するならtrueを返す。

4. falseを返す。

3.6.1. responseをrequestへのレスポンスとしてnosniffのためにブロックすべきか？

次の手順を実行する：

1. responseのヘッダーリストに対してnosniffを判定するがfalseなら、allowedを返す。

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

3. destinationをrequestのdestinationとする。

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

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

6. allowedを返す。

スクリプト系または"style"のdestinationだけが考慮されます。なぜならそれらに関連する攻撃があるためです。また、"image"は既存コンテンツとの互換性がありませんでした。

クロスオリジンリソースポリシーチェックを行うには、origin origin、環境設定オブジェクト settingsObject、文字列destination、response response、および省略可能なboolean forNavigationを与えて次の手順を実行する：

1. forNavigationが与えられていなければfalseとする。

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

3. クロスオリジンリソースポリシー内部チェックをorigin、"unsafe-none"、response、forNavigationで実行し、結果がblockedならblockedを返す。

   このステップは、Cross-Origin Embedder Policyに関連しない違反の報告を避けるために必要です。

4. クロスオリジンリソースポリシー内部チェックをorigin、embedderPolicyのレポート専用値、response、forNavigationで実行し、結果がblockedなら クロスオリジン埋め込み者ポリシーCORP違反レポートをキューするをresponse、settingsObject、destination、trueで実行する。

5. クロスオリジンリソースポリシー内部チェックをorigin、embedderPolicyの値、response、forNavigationで実行し、結果がallowedならallowedを返す。

6. クロスオリジン埋め込み者ポリシーCORP違反レポートをキューするをresponse、settingsObject、destination、falseで実行する。

7. blockedを返す。

HTMLのナビゲートアルゴリズムのみが、このチェックをforNavigationをtrueに設定して使用し、常にネストされたナビゲーションのために行われます。それ以外では、responseは内部レスポンスであり、不透明なフィルタリングされたレスポンスの内部レスポンスであるか、またはレスポンスであり、それが内部レスポンスである不透明なフィルタリングされたレスポンスとなります。[HTML]

クロスオリジンリソースポリシー内部チェックを行うには、 origin origin、埋め込み者ポリシー値 embedderPolicyValue、response response、boolean forNavigationを与えて次の手順を実行する：

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

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

   これは、`Cross-Origin-Resource-Policy: same-site, same-origin`のような場合は、embedderPolicyValueが"unsafe-none"である限り、下で何にも一致しないのでallowedとなる、という意味です。`Cross-Origin-Resource-Policy`ヘッダーが2つ以上あっても同様です。

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のoriginと同一オリジンならallowedを返す。

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

   `same-site`

   以下がすべて真なら

   • originがresponseのURLのoriginとスキームなし同一サイトである

   • originのスキームが"https"である、またはresponseのURLのスキームが"https"でない

   このときallowedを返す。

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

   `Cross-Origin-Resource-Policy: same-site`は、セキュアな伝送で配信されたレスポンスが、たとえホストが同一サイトでも非セキュアなリクエスト元とは一致しないことに注意。セキュアなレスポンスはセキュアなイニシエータとだけ一致する。

クロスオリジン埋め込み者ポリシーCORP違反レポートをキューするには、 response response、環境設定オブジェクト settingsObject、文字列destination、boolean reportOnlyを与えて次の手順を実行する：

1. endpointをsettingsObjectのポリシーコンテナの埋め込み者ポリシーのreport only reporting endpoint（reportOnlyがtrueかつ settingsObjectのポリシーコンテナの埋め込み者ポリシーの時）、それ以外はreporting endpointとする。

2. serializedURLをresponseでreporting用レスポンス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、失敗、またはバイト列を受け取るアルゴリズムでなければなりません。

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

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

1. アサート：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のクロスオリジン分離機能を設定する。

6. useParallelQueueがtrueであれば、taskDestinationに新しい並列キューの開始の結果を設定する。

7. timingInfoを新しいフェッチタイミング情報として生成し、その開始時刻とリダイレクト後開始時刻を粗化された共有現在時刻（crossOriginIsolatedCapabilityを指定）で設定し、レンダーブロッキングはrequestのレンダーブロッキングで設定する。

8. fetchParamsを新しいフェッチパラメータとして生成し、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ボディとしてで設定する。

10. 以下すべての条件を満たす場合：

    • requestのURLのスキームがHTTP(S)スキーム

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

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

    • requestのmethodが `GET`

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

    この場合：

    1. アサート：requestのoriginがrequestのclientの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を指定して呼び出した結果を設定する。

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

11. requestのheader listが`Accept`を含まない場合：

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

    2. requestのinitiatorが"prefetch"であれば、valueをドキュメント`Accept`ヘッダー値に設定する。

    3. それ以外の場合、ユーザーエージェントはrequestのdestinationに応じて、下記の最初に一致する項目でvalueを設定するべきです：

       "document"

       "frame"

       "iframe"

       ドキュメント`Accept`ヘッダー値

       "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`

    4. 追加（`Accept`, value） を request の ヘッダーリストに追加する。

12. request の header list が `Accept-Language` を含まない かつ request の client が null でない場合：

    1. emulatedLanguage を request の WebDriver BiDi emulated language （ request の client 用）とする。

    2. emulatedLanguage が null でない場合：

       1. encodedEmulatedLanguage を emulatedLanguage の isomorphic encode 後の値とする。

       2. 追加 （`Accept-Language`、encodedEmulatedLanguage）を request の header list に行う。

13. もし request の header list が `Accept-Language` を含まない 場合、 ユーザーエージェントは 追加 （`Accept-Language`、適切な header value）を request の header list に行うべきである。

14. requestの内部優先度がnullであれば、requestのpriority、initiator、destination、およびレンダーブロッキングを用いて、実装定義の方法でrequestの内部優先度に実装定義のオブジェクトを設定する。

    実装定義のオブジェクトは、HTTP/2のストリーム重みや依存性、HTTP/3などのトランスポートで利用されるExtensible Prioritization Scheme for HTTPの優先度、またはHTTP/1フェッチのディスパッチ・処理の優先度などを含む場合があります。[RFC9218]

15. requestがサブリソースリクエストであれば：

    1. recordを新しいフェッチレコードとして生成し、requestにrequest、controllerにfetchParamsのcontrollerを設定する。

    2. recordをrequestのclientのフェッチグループのフェッチレコードリストに追加する。

16. メインフェッチをfetchParamsで実行する。

17. fetchParamsのcontrollerを返す。

クライアントからリクエストを埋め込むには、リクエストrequestを指定して以下を実行します：

1. requestのユーザープロンプト用トラバーサブルが"client"であれば：

   1. requestのユーザープロンプト用トラバーサブルを"no-traversable"に設定する。

   2. requestのclientがnullでなければ：

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

      2. globalがWindowオブジェクトであり、かつglobalのnavigableがnullでなければ、requestのユーザープロンプト用トラバーサブルをglobalのnavigableのtraversable navigableで設定する。

2. requestのoriginが"client"であれば：

   1. アサート：requestのclientがnullでないこと。

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

3. requestのポリシーコンテナが"client"であれば：

   1. requestのclientがnullでなければ、requestのpolicy containerをrequestのclientのポリシーコンテナの複製に設定する。[HTML]

   2. それ以外の場合、requestの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のフェッチ時などです。

17. internalResponseのリダイレクト汚染にrequestのredirect-taintを設定する。

18. requestのtiming allow failed flagが未設定なら、internalResponseのtiming allow passed flagを設定する。

19. responseがネットワークエラーでなく、かつ下記のどれかがblockedを返す場合

    • 混在コンテンツとしてinternalResponseをrequestに対してブロックすべきか

    • Content Security PolicyによりinternalResponseをrequestに対してブロックすべきか

    • MIMEタイプによりinternalResponseをrequestに対してブロックすべきか

    • nosniffによりinternalResponseをrequestに対してブロックすべきか

    この場合responseとinternalResponseをネットワークエラーに設定する。

20. responseのtypeが"opaque"で、internalResponseのstatusが206で、internalResponseのrange-requested flagがセットされていて、かつrequestのheader listが`Range`を含まない場合、responseとinternalResponseをネットワークエラーに設定する。

    従来、APIは範囲指定がなくても範囲レスポンスを受け入れます。これは、以前の範囲リクエストからの部分レスポンスがAPIに提供されることを防ぎます。

    詳細

    上記の手順は以下の攻撃を防ぎます：

    メディア要素でクロスオリジンHTMLリソースの範囲をリクエストします（これは無効なメディア）。ただしレスポンスのクローン参照をService Workerに保持できます。後でこの部分レスポンスをscript要素のfetchレスポンスとして利用できます。もし部分レスポンスが有効なJavaScriptなら（リソース全体はそうでなくても）、実行するとプライベートデータが漏洩します。

21. responseがネットワークエラーでなく、かつrequestのmethodが`HEAD`または`CONNECT`である、またはinternalResponseのstatusがnullボディステータスであれば、internalResponseのbodyをnullに設定し、以降のエンキューは無視する。

    この処理はHTTP違反サーバへのエラー処理の標準化です。

22. requestのintegrity metadataが空文字列でなければ、以下を実行する：

    1. processBodyErrorにこの手順：fetch response handoverをfetchParamsとネットワークエラーで実行する。

    2. responseのbodyがnullならprocessBodyErrorを実行し、以降の手順を中止する。

    3. processBodyにbytesを受け取った場合の手順を設定する：

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

       2. responseのbodyにbytesボディとしてを設定する。

       3. fetch response handoverをfetchParamsとresponseで実行する。

    4. 完全に読み取るをresponseのbodyに対してprocessBodyとprocessBodyErrorで実行する。

23. それ以外の場合、fetch response handoverをfetchParamsとresponseで実行する。

フェッチレスポンス引き渡しは、フェッチパラメータ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. internalResponseのbodyがnullなら、processResponseEndOfBodyを実行する。

8. それ以外の場合：

   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は、ストリームの終端到達時の通知目的で必要です。それ以外は恒等変換ストリームです。

9. 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 request を受け取り、response または null を返す。その動作は 実装定義であり、ユーザーエージェントが request に直接レスポンスを返すか、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 を返す。

環境を決定するためには、request request を受け取る：

1. request の reserved client が null でなければ、 request の reserved client を返す。

2. request の client が null でなければ、 request の client を返す。

3. null を返す。

HTTPフェッチは、 fetch params fetchParams と、オプションの boolean makeCORSPreflight（デフォルトは false）を受け取り、以下の手順を実行する：

1. request を fetchParams の request とする。

2. response と internalResponse を null とする。

3. request の service-workers mode が "all" の場合：

   1. requestForServiceWorker を clone で request を複製したものとする。

   2. requestForServiceWorker の body が null でなければ：

      1. transformStream を新しい TransformStream とする。

      2. transformAlgorithm を chunk を受け取るアルゴリズムとして以下とする：

         1. fetchParams が キャンセル済みなら、これらの手順を中止する。

         2. chunk が Uint8Array オブジェクトでなければ、 terminate で fetchParams の controller を終了する。

         3. それ以外の場合、enqueue で chunk を transformStream に追加する。ユーザーエージェントは、チャンクを 実装定義の適切なサイズに分割して enqueue してもよいし、チャンク群を 実装定義の適切なサイズに連結して enqueue してもよい。

      3. transformStream を transformAlgorithm にセットアップする。

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

   3. serviceWorkerStartTime を coarsened shared current time を fetchParams の cross-origin isolated capability で実行した結果とする。

   4. fetchResponse を handle fetch に requestForServiceWorker、fetchParams の controller および fetchParams の cross-origin isolated capability とともに渡して呼び出した結果とする。 [HTML] [SW]

   5. もし fetchResponse が response の場合:

      1. response に fetchResponse を設定する。

      2. fetchParams の timing info の final service worker start time に serviceWorkerStartTime を設定する。

      3. fetchParams の timing info の service worker timing info に response の service worker timing info を設定する。

      4. もし request の body が null でない場合、 cancel を request の body に undefined で適用する。

      5. internalResponse を response に設定する。ただし、response が filtered response であれば、 response の internal response に設定する。

      6. 次のいずれか真の場合

         • response の type が "error" である

         • request の mode が "same-origin" で、かつ response の type が "cors" である

         • request の mode が "no-cors" でなく、かつ response の type が "opaque" である

         • request の redirect mode が "manual" でなく、かつ response の type が "opaqueredirect" である
         • request の redirect mode が "follow" でなく、かつ response の URL list が 2 つ以上の項目を持つ場合

         その場合、network error を返す。

   6. それ以外の場合、fetchResponse が service worker timing info であれば、 fetchParams の timing info の service worker timing info に fetchResponse を設定する。

4. response が null の場合：

   1. makeCORSPreflight が true かつ以下のいずれかが真の場合：

      • method cache entry match が request の method で存在せず、かつ request の method が CORS-safelisted method でないか、 request の use-CORS-preflight flag が設定されている場合

      • item が CORS-unsafe request-header names に存在し、 request の header list に該当し、 header-name cache entry match が request に対して存在しない場合

      この場合：

      1. preflightResponse を CORSプリフライトフェッチ を request で実行した結果とする。

      2. preflightResponse が ネットワークエラーの場合、 preflightResponse を返す。

      この手順は CORSプリフライトキャッシュ を確認し、 適切なエントリがなければ CORSプリフライトフェッチ を行い、成功すればキャッシュに登録する。 CORSプリフライトフェッチ の目的は 取得されるリソースが CORSプロトコルに対応していることを保証することである。 キャッシュは CORSプリフライトフェッチ の回数を減らすためにある。

   2. request の redirect mode が "follow" の場合、 request の service-workers mode を "none" に設定する。

      ネットワーク由来のリダイレクト（サービスワーカー由来でない場合）はサービスワーカーに公開しない。

   3. response と internalResponse を HTTPネットワークまたはキャッシュフェッチ を fetchParams で実行した結果に設定する。

   4. request の response tainting が "cors" かつ CORSチェック を request と response で実行した結果が失敗の場合、 ネットワークエラー を返す。

      status が 304 または 407 の response や、サービスワーカーからの response には CORS チェック を適用しないため、ここで適用される。

   5. TAOチェック を request と response で実行した結果が失敗なら、 request の timing allow failed flag を設定する。

5. もし request の response tainting または response の type が "opaque" であり、さらに cross-origin resource policy check を request の origin、 request の client、request の destination、および internalResponse に対して実行した結果が blocked を返すなら、 network error を返す。

   cross-origin resource policy check は、 ネットワークからのレスポンスおよびサービスワーカーからのレスポンスに対して実行される。これは CORS check とは異なり、request の client とサービスワーカーでは、異なる埋め込みポリシーを持ち得る。

6. internalResponse の status が リダイレクトステータスの場合：

   1. internalResponse の status が 303 でなく request の body が null でなく connection が HTTP/2 を利用している場合、 ユーザーエージェントは RST_STREAM フレームを送信してもよい（推奨）。

      303 は特定コミュニティで特別視されるため除外されている。

   2. request の redirect mode に応じて：

      "error"

      1. response を ネットワークエラー に設定する。

      "manual"

      1. request の mode が "navigate" の場合、 fetchParams の controller の next manual redirect steps に HTTPリダイレクトフェッチ を fetchParams と response で実行する手順を設定する。

      2. それ以外の場合、 response を opaque-redirect filtered response に設定し、 その internal response を internalResponse にする。

      "follow"

      1. response を HTTPリダイレクトフェッチ を fetchParams と response で実行した結果に設定する。

7. response を返す。通常、internalResponse の body の stream は この返却後もエンキューされ続けている。