Fetch API-リダイレクトの使用方法：手動
私は最近、Javascript Fetch APIで遊んでいます。私の知る限り、デフォルトではすべてのリダイレクトは透過的に処理され、最終的にリダイレクトチェーンの最後の呼び出しから応答を受け取ります。
ただし、{redirect： 'manual'}を使用してfetchを呼び出すことができます。この場合、使用可能な情報がない不透明なリダイレクト応答が返されます。から https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect
不透明リダイレクトフィルター済み応答は、タイプが「opaqueredirect」、ステータス0、ステータスメッセージが空のバイトシーケンス、ヘッダーリストが空、本文がヌル、トレーラーが空のフィルター済み応答です。
https://fetch.spec.whatwg.org/#http-fetch は、リダイレクトが 'manual'に設定されている場合、応答がopaqueredirectになることを示します。
リクエストのリダイレクトモードをオンにします。
...
-マニュアル
応答を、内部応答がactualResponseである不透明リダイレクトフィルター済み応答に設定します。
仕様には次のようにも書かれています。
つまり、不透明なフィルター処理された応答と不透明なリダイレクトフィルター処理された応答は、ネットワークエラーとほとんど区別できません。
これらすべてを考えると、Fetch APIを使用するときに手動にリダイレクトを設定するのはなぜですか？私にはかなり役に立たないようです。これが役立つユースケースはありますか？
簡単な答えは次のとおりだと思います： https://github.com/whatwg/fetch/issues/66 のようなサービスワーカーのコードを使用して何かをしているのでない限り、 redirect: 'manual'。
長い答え：
HTML仕様が必要と思われる ブラウザーが最初にリダイレクトモードをmanualに設定するのは、ブラウザーがリソースへのナビゲートを開始する前に、…（リダイレクト）unset mode unset？ （この場合、デフォルトはfollowに戻ります。）仕様のアルゴリズムがそのように動作する理由はわかりませんが、ナビゲーションが失敗した場合の処理と関係があると思います。とにかく、manualリダイレクトモードの仕様では、これが唯一の使用方法だと思います。
とにかく、Fetch APIは、ブラウザーがフェッチで使用するすべての同じプリミティブを公開するように設計されていますが、それは、Webアプリコードでこれらのプリミティブが常に適切に使用されることを意味しません（ブラウザー自体が使用するのとは対照的です）プリミティブ）。
したがって、Fetch仕様では、couldAPIをredirect: 'manual'、そうするとブラウザがスローされます。当時は、ナビゲーションを行うブラウザ以外の場合に設定される正当な理由を誰も提出していないためだと思います。
しかし、その振る舞いは https://github.com/whatwg/fetch/issues/66 により変更されたようです。これはredirect: 'manual'は、サービスワーカーのコードに必要です。
Fetch APIで設定できるものの、web-appコードでのユーティリティがほとんどない同様のケースはmode: 'no-cors'。ブラウザが特定のリクエストに使用するという理由だけで最初に追加されたため、Fetch APIはそれを公開します。しかし、それはサービスワーカーだけに有用性が限られている別のケースです。応答をキャッシュするために、後で応答を調べる必要なくそのまま応答するためです（どのmode: 'no-cors'は、web-appコードの実行を防ぎます）。