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 の リダイレクト汚染度 を計算するには、以下の手順を実行する。戻り値は "same-origin"、"same-site"、または"cross-site" である。

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

2. lastURL を null にする。

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

4. 各 request の URLリスト の url ごとに：

   1. もし lastURL が null ならば、lastURL に url を設定し、 次へ 続行。

   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. 確認: request の origin は "client" ではない。

2. request の リダイレクト汚染度 が "same-origin" でなければ、"null" を返す。

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

リクエストオリジンのバイト直列化 は リクエスト request を引数とし、リクエストオリジンの直列化 を request で実行し、 等価エンコード した結果を返す。

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

1. newRequest に request のコピーを作成するが、 body は除く。

2. request の body が null でなければ、 newRequest の body に クローン結果を設定する。

3. newRequest を返す。

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

1. 確認: last が指定されていなければ、または first が last 以下であること。

2. rangeValue に bytes= をセット。

3. 整数を直列化して 等価エンコードしたfirstを rangeValue に追加。

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

5. last が与えられていれば、 直列化し 等価エンコードし、rangeValue に追加。

6. Append (`Range`, rangeValue) を request の ヘッダーリスト に追加。

レンジヘッダーは包括的なバイト範囲を示す。 first が 0、last が 500 の場合、範囲は 501 バイトとなる。

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

レスポンス response について、 報告用にレスポンスURLを直列化するには、次の手順を実行する：

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

2. url に response の URLリスト[0] のコピーをセット。

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

3. ユーザー名を設定 し、url に空文字列をセット。

4. パスワードを設定 し、url に空文字列をセット。

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

Cross-Origin-Embedder-Policy が認証情報を許可するか確認する には、 リクエスト request を与え、次の手順を実行する：

1. 確認: 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" でなければ 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、 真偽値 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）の結果とする。

3. もし request の レスポンス汚染 が "cors" であるか、 または request の モード が "websocket" または "webtransport" であれば、 追加 (`Origin`, serializedOrigin) を request の ヘッダーリスト に行う。

4. そうでなく、request の メソッド が `GET` でも `HEAD` でもない場合：

   1. request の モード が "cors" でなければ、 request の referrer policy を判定しswitch：

      "no-referrer"

      serializedOrigin を `null` に設定。

      "no-referrer-when-downgrade"

      "strict-origin"

      "strict-origin-when-cross-origin"

      もし request の origin が タプルorigin で、 その scheme が "https"、かつ request の 現在のURL の scheme が "https" でない場合、 serializedOrigin を `null` に設定。

      "same-origin"

      もし request の origin が request の 現在のURL の origin と 同一origin でなければ、 serializedOrigin を `null` に設定。

      その他

      何もしない。

   2. 追加 （`Origin`, serializedOrigin）を request の ヘッダーリスト に行う。

リクエストの referrer policy は、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" は実環境の内容と相性が悪かったため対象外。

Cross-Origin Resource Policy チェック を行うには、 オリジン origin、 環境設定オブジェクト settingsObject、 文字列 destination、 レスポンス response、 オプションで真偽値 forNavigation を与え以下の手順を行う：

1. forNavigation が与えられていなければ、false に設定する。

2. embedderPolicy を settingsObject の ポリシーコンテナ の エンベッダーポリシーとする。

3. コーポリシー内部チェックを origin、 "unsafe-none"、 response、 forNavigation で実行し blocked を返したら blocked を返す。

   このステップはCross-Origin Embedder Policyに関連しない違反は以下で報告しないために必要。

4. コーポリシー内部チェックを origin、 embedderPolicy の report only value、response、forNavigation で行い、 blocked なら CORP違反レポートをキュー ( response、settingsObject、destination、true ) を行う。

5. コーポリシー内部チェックを origin、 embedderPolicy の value、response、forNavigation で行い allowed なら allowed を返す。

6. CORP違反レポートをキュー ( response、settingsObject、destination、false ) を実施。

7. blocked を返す。

HTMLの navigateアルゴリズムだけがforNavigationをtrueにして使用するがこれは常に入れ子のナビゲーションのみ。 それ以外では response は internal responseまたは opaque filtered response の internal response となる。[HTML]

Cross-Origin Resource Policy 内部チェック を行うには オリジン origin、 エンベッダーポリシー値 embedderPolicyValue、 レスポンス response、 真偽値 forNavigation を与え以下の手順を行う：

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

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

   たとえば `Cross-Origin-Resource-Policy: same-site, same-origin` と書いても、embedderPolicyValueが"unsafe-none" であれば、下記ロジックに引っかからない限りallowedとなる。 2つ以上のCORPヘッダーを書いても同じ挙動。

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によりswitch:

   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`は安全なトランスポートで配信されたレスポンスは 非安全なリクエスト元オリジンとは一致しないことに注意。 同じホストであっても安全に運ばれたレスポンスは同じく安全な発信元のみ一致する。

Cross-Origin Embedder Policy CORP違反レポートをキューする には、 レスポンス response、 環境設定オブジェクト settingsObject、 文字列 destination、真偽値 reportOnly を与え以下の手順を行う：

1. endpoint を settingsObject の ポリシーコンテナ の エンベッダーポリシーの report only reporting endpoint、 ただし reportOnly が true の場合であり、 false の場合は ポリシーコンテナの エンベッダーポリシー の reporting endpoint。

2. serializedURL を 報告用レスポンスURL直列化(response) の結果とする。

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

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

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

5. レポートを生成しキュー ( settingsObject のグローバルオブジェクト、 "coep" report type、 endpoint、 body) を呼び出す。[REPORTING]

To fetch, given a request request, an optional algorithm processRequestBodyChunkLength, an optional algorithm processRequestEndOfBody, an optional algorithm processEarlyHintsResponse, an optional algorithm processResponse, an optional algorithm processResponseEndOfBody, an optional algorithm processResponseConsumeBody, and an optional boolean useParallelQueue (default false), run the steps below. If given, processRequestBodyChunkLength must be an algorithm accepting an integer representing the number of bytes transmitted. If given, processRequestEndOfBody must be an algorithm accepting no arguments. If given, processEarlyHintsResponse must be an algorithm accepting a response. If given, processResponse must be an algorithm accepting a response. If given, processResponseEndOfBody must be an algorithm accepting a response. If given, processResponseConsumeBody must be an algorithm accepting a response and null, failure, or a byte sequence。

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

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

1. Assert: request の mode が "navigate" であるか、processEarlyHintsResponse が null であること。

   early hints（ステータスが 103 の responses）の処理はナビゲーションに対してのみ精査されます。

2. taskDestination を null にする。

3. crossOriginIsolatedCapability を false にする。

4. Populate request from client を与えられた request に対して実行する。

5. もし request の client が null でないならば：

   1. taskDestination を request の client の global object に設定する。

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

6. もし useParallelQueue が true なら、taskDestination を starting a new parallel queue の結果に設定する。

7. timingInfo を新しい fetch timing info として定め、その start time と post-redirect start time を coarsened shared current 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 が byte sequence であるなら、request の body を request の body の as a body に設定する。

10. もし 次のすべての条件が真であるなら：

    • request の URL の scheme が HTTP(S) scheme

    • request の mode が "same-origin", "cors"、または "no-cors" のいずれかであること

    • request の client が null でなく、かつ request の client の global object が Window オブジェクトであること

    • request の method が `GET` であること

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

    ならば：

    1. Assert: request の origin が same origin であり、 request の client の origin と同じであること。

    2. onPreloadedResponseAvailable を、次の手順を与えられた response response に対して実行するアルゴリズムとして定める：fetchParams の preloaded response candidate を response に設定する。

    3. foundPreloadedResource を、consume a preloaded resource を 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 を 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`

    4. Append (`Accept`, value) を request の header list に追加する。

12. もし request の header list が `Accept-Language` を 含んでおらず かつ request の client が null でない場合:

    1. emulatedLanguage を WebDriver BiDi emulated language として求める（request の client に対する）。

    2. もし emulatedLanguage が null でないなら:

       1. 次に、encodedEmulatedLanguage を emulatedLanguage とし、 同型にエンコードされた.

       2. Append (`Accept-Language`, encodedEmulatedLanguage) を request の header list に追加する。

13. もし request の header list が `Accept-Language` を 含んでいない なら、ユーザーエージェントは append (`Accept-Language, 適切な header value）を request の header list に追加すべきです。

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

    その implementation-defined オブジェクトは、 HTTP/2 用のストリームの重みや依存、適用されるトランスポート（HTTP/3 を含む）で用いられる Extensible Prioritization Scheme for HTTP の優先度、または HTTP/1 フェッチの 発行と処理の優先度付けに使われる同等の情報を包含する可能性があります。 [RFC9218]

15. もし request が subresource request であるなら：

    1. record を新しい fetch record として定め、その request が request であり、かつ controller が fetchParams の controller であるようにする。

    2. Append record を request の client の fetch group の fetch records に追加する。

16. main fetch を fetchParams に対して実行する。

17. fetchParams の controller を返す。

To populate request from client given a request request:

1. もし request の traversable for user prompts が "client" なら：

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

   2. もし request の client が null でないなら：

      1. global を request の client の global object に設定する。

      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 を clone によって 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のフェッチ時などです。

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 が レンジステータス で、 internalResponse の range-requested フラグ が設定されており、かつ request の ヘッダーリスト に `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 を受け取り、レスポンス または 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 を返す。

環境を決定するためには、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 は この返却後もエンキューされ続けている。