Fetch API - Quelle est l'utilité de la redirection: manuelle
J'ai récemment joué avec l'API Javascript Fetch. D'après ce que je comprends, par défaut, toutes les redirections sont gérées de manière transparente et, à la fin, j'obtiens une réponse du dernier appel de la chaîne de redirection.
Cependant, je pouvais invoquer fetch avec {redirect: 'manual'}, auquel cas il retournerait une réponse opaqueredirect sans aucune information utilisable. De https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect
Une réponse filtrée par redirection opaque est une réponse filtrée dont le type est "opaqueredirect", l'état est 0, le message d'état est la séquence d'octets vide, la liste d'en-tête est vide, le corps est nul et la bande-annonce est vide.
https://fetch.spec.whatwg.org/#http-fetch indique qu'une réponse doit être opaqueredirect si la redirection est définie sur 'manual':
Activez le mode de redirection de la demande:
...
- Manuel
Définissez la réponse sur une réponse filtrée par redirection opaque dont la réponse interne est actualResponse.
La spécification dit également:
En d'autres termes, une réponse filtrée opaque et une réponse filtrée par redirection opaque sont presque indiscernables d'une erreur réseau.
Compte tenu de tout cela, pourquoi définir une redirection vers manuelle lors de l'utilisation de l'API Fetch? Cela me semble assez inutile. Existe-t-il des cas d'utilisation où cela serait utile?
Je pense que la réponse courte est: à moins que vous ne fassiez quelque chose avec du code de service-worker comme quoi https://github.com/whatwg/fetch/issues/66 décrit, vous ne voulez jamais redirect: 'manual'.
Réponse plus longue:
Les navigateurs les spécifications HTML semblent nécessiter pour définir initialement le mode de redirection sur manual lorsque le navigateur commence à naviguer vers une ressource, avant cela… (re) le faire avec le mode de redirection non défini? (Dans ce cas, il revient par défaut à follow.) Je ne comprends pas pourquoi l'algorithme de la spécification le fait de cette façon, mais je suppose qu'il doit avoir quelque chose à voir avec la gestion du cas où la navigation échoue. Quoi qu'il en soit, je pense que c'est la seule utilisation dans n'importe quelle spécification pour le mode de redirection manual.
Quoi qu'il en soit, l'API Fetch est conçue pour exposer toutes les mêmes primitives que les navigateurs utilisent dans les récupérations, mais cela ne signifie pas qu'il existe toujours de bonnes utilisations pour ces primitives dans le code de l'application Web (contrairement à l'utilisation que les navigateurs eux-mêmes font de la primitives).
Je pense donc que la spécification Fetch exigeait que même si vous pourriez appeler l'API avec redirect: 'manual', les navigateurs lanceraient si vous le faisiez - je suppose que, à l'époque, personne n'avait encore avancé de raison valable pour qu'il soit défini pour un cas autre que les navigateurs faisant des navigations.
Mais ce comportement semble avoir été modifié en raison de https://github.com/whatwg/fetch/issues/66 qui décrit un cas (d'angle) où redirect: 'manual' est nécessaire dans le code du service-worker.
Un cas similaire de quelque chose que vous pouvez définir dans l'API Fetch mais avec très peu d'utilité dans le code de l'application Web est mode: 'no-cors'. Cela a été initialement ajouté simplement parce que les navigateurs l'utilisent pour certaines demandes, donc l'API Fetch l'expose. Mais c'est un autre cas qui a une utilité limitée uniquement pour les travailleurs des services - pour la mise en cache des réponses afin qu'elles soient renvoyées telles quelles plus tard sans qu'il soit nécessaire d'examiner les réponses (qui mode: 'no-cors' empêche le code de l'application Web de le faire).