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とともに。

文字列 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ヘッダーを追加で設定できます。

ボディ 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 の レスポンステインティング が "cors" または request の モード が "websocket" の場合、 追加 (`Origin`, serializedOrigin) を request の ヘッダーリスト に追加する。

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 の ヘッダーリスト が `Accept-Language` を含まない場合、ユーザーエージェントは 追加（`Accept-Language`, 適切な ヘッダー値）を request の ヘッダーリストに追加するべきです。

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

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

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

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

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

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

16. 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"である

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

    2. スキームフェッチをfetchParamsで実行した結果を返す。

    HTMLは、URLのschemeが"data"のものから作成されるドキュメントやワーカーに一意の不透明オリジンを割り当てます。Service WorkerはURLのschemeがHTTP(S)スキームのもののみから作成可能です。[HTML] [SW]

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

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

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

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

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

    3. スキームフェッチをfetchParamsで実行した結果を返す。

    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フェッチをfetchParamsとtrueで実行した結果を設定する。

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

    4. corsWithPreflightResponseを返す。

    その他

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

    2. HTTPフェッチをfetchParamsで実行した結果を返す。

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で実行する。

スキームフェッチするには、フェッチパラメータfetchParamsを指定して以下を実行する：

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

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

3. requestのcurrent URLのschemeに応じて下記を実行：

   "about"

   requestのcurrent URLのpathが"blank"なら、新しいレスポンス（status messageが`OK`、header listが« (`Content-Type`, `text/html;charset=utf-8`) »、bodyが空バイト列ボディとして）を返す。

   URL（例: "about:config"）はナビゲーション中に処理され、フェッチング時にはネットワークエラーとなる。

   "blob"

   1. blobURLEntryにrequestのcurrent URLのblob URLエントリを設定する。

   2. requestのmethodが`GET`でない、またはblobURLEntryがnullならネットワークエラーを返す。[FILEAPI]

      `GET`メソッドの制限は相互運用のためのみで有用性はない。

   3. requestEnvironmentに環境決定（request）の結果を設定する。

   4. isTopLevelNavigationにrequestのdestinationが"document"ならtrue、そうでなければfalseを設定する。

   5. isTopLevelNavigationがfalseかつrequestEnvironmentがnullならネットワークエラーを返す。

   6. navigationOrEnvironmentにisTopLevelNavigationがtrueなら文字列"navigation"、そうでなければrequestEnvironmentを設定する。

   7. blobにblobオブジェクト取得（blobURLEntry, navigationOrEnvironment）の結果を設定する。

   8. blobがBlobでなければネットワークエラーを返す。

   9. responseに新しいレスポンスを設定する。

   10. fullLengthにblobのsizeを設定する。

   11. serializedFullLengthにfullLengthを直列化・同型エンコードした値を設定する。

   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に取得（`Range`, requestのheader list）の結果を設定する。

       3. rangeValueに単一レンジヘッダー値解析（rangeHeader, true）の結果を設定する。

       4. rangeValueが失敗ならネットワークエラーを返す。

       5. (rangeStart, rangeEnd)にrangeValueを設定する。

       6. rangeStartがnullなら：

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

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

       7. それ以外の場合：

          1. rangeStartがfullLength以上ならネットワークエラーを返す。

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

       8. slicedBlobにスライスblob（blob, rangeStart, rangeEnd + 1, type）の結果を設定する。

          Rangeヘッダーは両端含むバイト範囲だが、slice blobアルゴリズムは非包含なのでrangeEndを+1する必要あり。

       9. slicedBodyWithTypeに安全抽出（slicedBlob）の結果を設定する。

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

       11. serializedSlicedLengthにslicedBlobのsizeを直列化・同型エンコードした値を設定する。

       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にdata:URLプロセッサ（requestのcurrent URL）の結果を設定する。

   2. dataURLStructが失敗ならネットワークエラーを返す。

   3. mimeTypeにdataURLStructのMIME typeを直列化したものを設定する。

   4. 新しいレスポンス（status messageが`OK`、header listが« (`Content-Type`, mimeType) »、bodyがdataURLStructのbodyボディとして）を返す。

   "file"

   現段階ではfile:URLは読者の演習に委ねます。

   不明な場合はネットワークエラーを返すこと。

   HTTP(S)スキーム

   HTTPフェッチ（fetchParams）の結果を返す。

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

環境決定は、リクエストrequestに対して以下を実行する：

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

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

3. nullを返す。

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

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

2. responseとinternalResponseをnullに設定する。

3. requestのservice-workers modeが"all"なら：

   1. requestForServiceWorkerにrequestのクローンを設定する。

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

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

      2. transformAlgorithmにchunkを受け取ったときの以下の手順を設定する：

         1. fetchParamsがキャンセル済みなら以降を中止する。

         2. chunkがUint8ArrayでなければfetchParamsのcontrollerをterminateする。

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

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

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

   3. serviceWorkerStartTimeに粗化された共有現在時刻（fetchParamsのcross-origin isolated capability）を設定する。

   4. responseにhandle fetch（requestForServiceWorker、fetchParamsのcontrollerとcross-origin isolated capability）の結果を設定する。[HTML] [SW]

   5. responseがnullでなければ：

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

      2. requestのbodyがnullでなければcancel（requestのbody、undefined）を実行する。

      3. internalResponseにresponseがフィルタ済みレスポンスでなければresponse、そうであればresponseの内部レスポンスを設定する。

      4. 以下のいずれかがtrueなら：

         • 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リストが2つ以上ある

         この場合ネットワークエラーを返す。

4. responseがnullなら：

   1. makeCORSPreflightがtrueで、以下のいずれかがtrueなら：

      • requestのmethodでメソッドキャッシュエントリ一致が無く、かつrequestのmethodがCORS安全リストメソッドでなく、またはrequestのuse-CORS-preflight flagがセットされている

      • requestのheader listのCORS安全でないリクエストヘッダー名にitemがあり、かつヘッダー名キャッシュエントリ一致が無い

      この場合：

      1. preflightResponseにCORSプリフライトフェッチ（request）の結果を設定する。

      2. preflightResponseがネットワークエラーならpreflightResponseを返す。

      この手順はCORSプリフライトキャッシュを確認し、適切なエントリがなければCORSプリフライトフェッチを実施し、成功すればキャッシュを更新する。CORSプリフライトフェッチの目的は取得したリソースがCORSプロトコルを理解しているか確認すること。キャッシュはCORSプリフライトフェッチを最小限にするためにある。

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

      ネットワーク由来のリダイレクト（Service Worker由来でない）はService Workerに露出してはならない。

   3. HTTP-network-or-cache fetch（fetchParams）の結果をresponseとinternalResponseに設定する。

   4. requestのresponse taintingが"cors"で、CORSチェック（request, response）が失敗ならネットワークエラーを返す。

      CORSチェックは304/407ステータスやService Worker由来レスポンスには適用されないが、ここでは適用する。

   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を返す場合、ネットワークエラーを返す。

   cross-origin resource policy checkはネットワーク由来とService Worker由来両方のレスポンスに適用される。CORSチェックとは異なり、requestのclientとService Workerは埋め込みポリシーが異なる可能性がある。

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-redirect fetch（fetchParams, response）を設定する。

      2. それ以外の場合、responseにopaque-redirectフィルタ済みレスポンス（内部レスポンスがinternalResponse）を設定する。

      "follow"

      1. responseにHTTP-redirect fetch（fetchParams, response）の結果を設定する。

7. responseを返す。通常はinternalResponseのbodyのstreamへのenqueueは返却後も継続している。

HTTPリダイレクトフェッチは、フェッチパラメータfetchParamsとレスポンスresponseを指定して以下を実行します：

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

2. internalResponseにresponseがフィルタ済みレスポンスでなければresponse、そうであればresponseの内部レスポンスを設定する。

3. locationURLにinternalResponseのlocation URL（requestのcurrent URLのfragmentを指定）を設定する。

4. locationURLがnullならresponseを返す。

5. locationURLが失敗ならネットワークエラーを返す。

6. locationURLのschemeがHTTP(S)スキームでなければネットワークエラーを返す。

7. requestのredirect countが20ならネットワークエラーを返す。

8. requestのredirect countを1増やす。

9. requestのmodeが"cors"で、locationURLが資格情報を含むで、requestのoriginがlocationURLのoriginと同一オリジンでなければネットワークエラーを返す。

10. requestのresponse taintingが"cors"で、locationURLが資格情報を含むならネットワークエラーを返す。

    これはクロスオリジンリソースが同一オリジンURLへリダイレクトする場合を捕捉します。

11. internalResponseのstatusが303以外で、requestのbodyがnullでなく、かつrequestのbodyのsourceがnullならネットワークエラーを返す。

12. 以下のいずれかがtrueなら：

    • internalResponseのstatusが301または302で、requestのmethodが`POST`

    • internalResponseのstatusが303で、requestのmethodが`GET`または`HEAD`でない

    この場合：

    1. requestのmethodを`GET`に、requestのbodyをnullに設定する。

    2. 各headerName（request-body-header name）についてrequestのheader listから削除する。

13. requestのcurrent URLのoriginがlocationURLのoriginと同一オリジンでなければ、各headerName（CORS非ワイルドカードリクエストヘッダー名）についてrequestのheader listから削除する。

    初回リクエスト以降に他のオリジンが現れた時点で`Authorization`ヘッダーは削除されます。

14. requestのbodyがnullでなければ、requestのbodyにbody（安全抽出（requestのbodyのsource）の結果）を設定する。

    requestのbodyのsourceがnullかどうかはすでに判定済みです。

15. timingInfoにfetchParamsのtiming infoを設定する。

16. timingInfoのredirect end timeとpost-redirect start timeに粗化された共有現在時刻（fetchParamsのcross-origin isolated capability）を設定する。

17. timingInfoのredirect start timeが0なら、timingInfoのredirect start timeにtimingInfoのstart timeを設定する。

18. locationURLをrequestのURLリストに追加する。

19. リダイレクト時のreferrer policy設定をrequestとinternalResponseで実行する。[REFERRER]

20. recursiveにtrueを設定する。

21. requestのredirect modeが"manual"なら：

    1. アサート：requestのmodeが"navigate"である。

    2. recursiveをfalseに設定する。

22. メインフェッチ（fetchParams, recursive）の結果を返す。

    これはrequestのresponse taintingを正しくするためにメインフェッチを呼び出す必要があります。

HTTPネットワークまたはキャッシュフェッチは、フェッチパラメータfetchParams、オプションのブール値isAuthenticationFetch（デフォルトはfalse）、オプションのブール値isNewConnectionFetch（デフォルトはfalse）を指定して以下を実行します：

一部の実装ではHTTPキャッシュに従って部分コンテンツのキャッシュをサポートする場合がありますが、ブラウザのキャッシュでは広くサポートされていません。 [HTTP-CACHING]

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

2. httpFetchParamsをnullに設定する。

3. httpRequestをnullに設定する。

4. responseをnullに設定する。

5. storedResponseをnullに設定する。

6. httpCacheをnullに設定する。

7. revalidatingFlagを未設定にする。

8. 以下の手順を実行するが、abort when fetchParamsがキャンセル済みの場合は中止する：

   1. requestのtraversable for user promptsが"no-traversable"で、かつrequestのredirect modeが"error"なら、httpFetchParamsをfetchParams、httpRequestをrequestに設定する。

   2. それ以外の場合：

      1. httpRequestにrequestのクローンを設定する。

         実装はrequestのbodyのstreamをteeすることを避けることが推奨されます。requestのbodyのsourceがnullの場合、単一ボディで十分です。例：bodyのsourceがnullの場合、リダイレクトや認証はフェッチ失敗となります。

      2. httpFetchParamsにfetchParamsのコピーを設定する。

      3. httpFetchParamsのrequestにhttpRequestを設定する。

      ユーザープロンプトやリダイレクトが発生する場合、ユーザーの応答やリダイレクト先が決まった後で再送する必要があるため、元のリクエストボディが部分的に送信されている場合を考慮して、事前にリクエスト（ボディ含む）を複製して予備を持っておく必要があります。

   3. includeCredentialsを以下いずれかがtrueならtrue、それ以外ならfalseに設定：

      • requestのcredentials modeが"include"
      • requestのcredentials modeが"same-origin"かつrequestのresponse taintingが"basic"

      がtrueの場合のみtrue。

   4. Cross-Origin-Embedder-Policyがcredentialsを許可するか（request）がfalseならincludeCredentialsをfalseに設定する。

   5. contentLengthにhttpRequestのbodyのlength（bodyがnullでなければ）を設定し、そうでなければnull。

   6. contentLengthHeaderValueをnullに設定する。

   7. httpRequestのbodyがnullで、かつhttpRequestのmethodが`POST`または`PUT`なら、contentLengthHeaderValueに`0`を設定する。

   8. contentLengthがnullでなければ、contentLengthHeaderValueにcontentLengthを直列化・同型エンコードしたものを設定する。

   9. contentLengthHeaderValueがnullでなければ、Content-Length（value:contentLengthHeaderValue）をhttpRequestのheader listに追加する。

   10. contentLengthがnullでなく、かつhttpRequestのkeepaliveがtrueなら：

       1. inflightKeepaliveBytesを0に設定する。

       2. groupにhttpRequestのclientのfetch groupを設定する。

       3. inflightRecordsにgroup内でfetch recordのうち、requestのkeepaliveがtrue・done flagが未設定のものの集合を設定する。

       4. 各fetchRecord（inflightRecordsの要素）について：

          1. inflightRequestにfetchRecordのrequestを設定する。

          2. inflightKeepaliveBytesにinflightRequestのbodyのlengthを加算する。

       5. contentLength＋inflightKeepaliveBytesが64KiBを超える場合はネットワークエラーを返す。

       上記の制限により、bodyを持ち環境設定オブジェクトの存続後も生存できるリクエストのサイズが制限され、無限に生存するのを防ぎます。

   11. httpRequestのreferrerがURLなら：

       1. referrerValueにhttpRequestのreferrerを直列化・同型エンコードしたものを設定する。

       2. Referer（referrerValue）をhttpRequestのheader listに追加する。

   12. OriginヘッダーをhttpRequestに追加する。

   13. FetchメタデータヘッダーをhttpRequestに追加する。 [FETCH-METADATA]

   14. httpRequestのinitiatorが"prefetch"なら、Sec-Purpose（値:token prefetch）をhttpRequestのheader listに構造化フィールド値として設定する。

   15. httpRequestのheader listがUser-Agentを含まない場合、ユーザーエージェントはUser-Agent（デフォルト値）をhttpRequestのheader listに追加するべきです。

   16. httpRequestのcache modeが"default"かつhttpRequestのheader listがIf-Modified-Since、If-None-Match、If-Unmodified-Since、If-Match、If-Rangeのいずれかを含む場合はhttpRequestのcache modeを"no-store"に設定する。

   17. httpRequestのcache modeが"no-cache"で、httpRequestのprevent no-cache cache-control header modification flagが未設定、かつhttpRequestのheader listがCache-Controlを含まない場合は、Cache-Control（value:max-age=0）をhttpRequestのheader listに追加する。

   18. httpRequestのcache modeが"no-store"または"reload"なら：

       1. httpRequestのheader listがPragmaを含まない場合、Pragma（value:no-cache）をhttpRequestのheader listに追加する。

       2. httpRequestのheader listがCache-Controlを含まない場合、Cache-Control（value:no-cache）をhttpRequestのheader listに追加する。

   19. httpRequestのheader listがRangeを含む場合、Accept-Encoding（value:identity）をhttpRequestのheader listに追加する。

       これはコンテンツ符号化を扱う際、符号化済みレスポンスの一部取得による失敗を回避します。

       さらに、多くのサーバーが非identity符号化を受け入れる場合Rangeヘッダーを無視する誤った実装があります。

   20. HTTPに従ってhttpRequestのheader listを修正する。同名ヘッダーが既に存在する場合は追加しない。

       より規範的にしたい部分。ここでAccept-Encoding、Connection、DNT、Hostヘッダーは必要なら追加される。

       Accept、Accept-Charset、Accept-Languageは含めてはいけない。

       AcceptとAccept-Languageは既に含まれており（fetch()使用時は後者はデフォルトで含まれない）、Accept-Charsetは無駄。詳細はHTTPヘッダー階層分離参照。

   21. includeCredentialsがtrueなら：

       1. CookieヘッダーをhttpRequestに追加する。

       2. httpRequestのheader listがAuthorizationを含まない場合：

          1. authorizationValueをnullに設定する。

          2. httpRequestに対する認証エントリがあり、かつhttpRequestのuse-URL-credentials flagが未設定またはhttpRequestのcurrent URLが資格情報を含まない場合、authorizationValueに認証エントリを設定する。

          3. それ以外でhttpRequestのcurrent URLが資格情報を含むかつisAuthenticationFetchがtrueならauthorizationValueにhttpRequestのcurrent URL（Authorization値に変換）を設定する。

          4. authorizationValueがnullでなければ、Authorization（value:authorizationValue）をhttpRequestのheader listに追加する。

   22. プロキシ認証エントリがあれば適切に利用する。

       これはhttpRequestのcredentials modeには依存しません。

   23. httpCacheにHTTPキャッシュパーティション判定（httpRequest）の結果を設定する。

   24. httpCacheがnullならhttpRequestのcache modeを"no-store"に設定する。

   25. httpRequestのcache modeが"no-store"でも"reload"でもない場合：

       1. storedResponseにhttpCacheからレスポンス選択（場合によって検証が必要）結果を設定する。詳細はHTTPキャッシュの「Constructing Responses from Caches」章参照。 [HTTP-CACHING]

          HTTPによりVaryヘッダーも考慮されます。

       2. storedResponseがnullでなければ：

          1. cache modeが"default"、かつstoredResponseがstale-while-revalidate response、かつhttpRequestのclientがnullでなければ：

             1. responseにstoredResponseを設定する。

             2. responseのcache stateを"local"に設定する。

             3. revalidateRequestにrequestのクローンを設定する。

             4. revalidateRequestのcache modeを"no-cache"に設定する。

             5. revalidateRequestのprevent no-cache cache-control header modification flagを設定する。

             6. revalidateRequestのservice-workers modeを"none"に設定する。

             7. 並列で新しいfetch params（request:revalidateRequest）でメインフェッチを実行する。

                このフェッチはhttpCacheの状態更新のみが目的で、現在のリクエストへのレスポンスとしては利用されません。クライアント文脈で発行されるため、クライアントが消失すればリクエストも終了します。

          2. それ以外の場合：

             1. storedResponseがstale responseならrevalidatingFlagを設定する。

             2. revalidatingFlagが設定済み、かつhttpRequestのcache modeが"force-cache"でも"only-if-cached"でもない場合：

                1. storedResponseのheader listがETagを含む場合、If-None-Match（value:ETagの値）をhttpRequestのheader listに追加する。

                2. storedResponseのheader listがLast-Modifiedを含む場合、If-Modified-Since（value:Last-Modifiedの値）をhttpRequestのheader listに追加する。

                詳細はHTTPキャッシュの「Sending a Validation Request」章参照。 [HTTP-CACHING]

             3. それ以外の場合、responseにstoredResponseを設定し、responseのcache stateを"local"に設定する。

9. もし中断された場合、fetchParamsに対して適切なネットワークエラーを返す。

10. responseがnullなら：

    1. httpRequestのcache modeが"only-if-cached"ならネットワークエラーを返す。

    2. forwardResponseにHTTPネットワークフェッチ（httpFetchParams、includeCredentials、isNewConnectionFetch）の結果を設定する。

    3. httpRequestのmethodがunsafeで、forwardResponseのstatusが200〜399なら、httpCache内の適切な保存レスポンスをHTTPキャッシュ「Invalidating Stored Responses」章に従い無効化し、storedResponseをnullに設定する。 [HTTP-CACHING]

    4. revalidatingFlagが設定済み、かつforwardResponseのstatusが304なら：

       1. storedResponseのheader listをforwardResponseのheader listで更新する。詳細はHTTPキャッシュ「Freshening Stored Responses upon Validation」章参照。 [HTTP-CACHING]

          キャッシュ内の保存レスポンスも更新されます。

       2. responseにstoredResponseを設定する。

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

    5. responseがnullなら：

       1. responseにforwardResponseを設定する。

       2. httpRequestとforwardResponseをHTTPキャッシュ「Storing Responses in Caches」章に従いhttpCacheに保存する。 [HTTP-CACHING]

          forwardResponseがネットワークエラーなら、これはいわゆる「ネガティブキャッシュ」としてエラーもキャッシュされます。

          関連するbody infoもレスポンスと一緒にキャッシュに保存されます。

11. responseのURLリストにhttpRequestのURLリストの複製を設定する。

12. httpRequestのheader listがRangeを含む場合、responseのrange-requested flagを設定する。

13. responseのrequest-includes-credentialsにincludeCredentialsを設定する。

14. responseのstatusが401、かつhttpRequestのresponse taintingが"cors"でなく、includeCredentialsがtrue、かつrequestのtraversable for user promptsがtraversable navigableの場合：

    1. 要検証：複数WWW-Authenticateヘッダー、欠落、パース問題。

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

       1. requestのbodyのsourceがnullならネットワークエラーを返す。

       2. requestのbodyにbody（安全抽出（requestのbodyのsource）の結果）を設定する。

    3. requestのuse-URL-credentials flagが未設定、またはisAuthenticationFetchがtrueなら：

       1. fetchParamsがキャンセル済みならfetchParamsに対する適切なネットワークエラーを返す。

       2. usernameとpasswordにrequestのtraversable for user promptsでエンドユーザーに入力を促して取得する。

       3. set the username（requestのcurrent URL, username）を実行する。

       4. set the password（requestのcurrent URL, password）を実行する。

    4. responseにHTTPネットワークまたはキャッシュフェッチ（fetchParams, true）を実行した結果を設定する。

15. responseのstatusが407の場合：

    1. requestのtraversable for user promptsが"no-traversable"ならネットワークエラーを返す。

    2. 要検証：複数Proxy-Authenticateヘッダー、欠落、パース問題。

    3. fetchParamsがキャンセル済みならfetchParamsに対する適切なネットワークエラーを返す。

    4. requestのtraversable for user promptsで適切にユーザー入力を促し、proxy-authentication entryとして保存する。[HTTP]

       プロキシ認証に関する追加詳細はHTTPで定義されています。

    5. responseにHTTPネットワークまたはキャッシュフェッチ（fetchParams）の結果を設定する。

16. 以下すべてがtrueの場合：

    • responseのstatusが421

    • isNewConnectionFetchがfalse

    • requestのbodyがnull、またはrequestのbodyがnullでなくrequestのbodyのsourceがnullでない

    この場合：

    1. fetchParamsがキャンセル済みならfetchParamsに対する適切なネットワークエラーを返す。

    2. responseにHTTPネットワークまたはキャッシュフェッチ（fetchParams、isAuthenticationFetch、true）の結果を設定する。

17. isAuthenticationFetchがtrueならrequestとrealmに対する認証エントリを作成する。

18. responseを返す。通常はresponseのbodyのstreamへのenqueueは返却後も継続している。