Article original : The Story of requesting twice - CORS
Par Lusan Das
L'histoire de la double requête, permettez-moi d'expliquer comment tout a commencé.
En travaillant sur une fonctionnalité, j'ai décidé de regarder l'onglet réseau et j'ai observé que la première requête était envoyée avec la méthode OPTIONS, et la requête suivante après celle-ci était la requête avec la méthode correcte, par exemple GET, POST, etc., qui retourne la charge utile attendue. Basique, deux appels pour la même requête.
Voici, regardez les captures d'écran ci-dessous
Requête avec la méthode OPTIONS
Requête avec la méthode GET
Après avoir creusé quelques documents, j'ai réalisé que c'était un comportement attendu. Cela est lié au concept de contrôle d'accès HTTP (CORS).
Pour mieux le comprendre, permettez-moi d'expliquer un peu sur CORS et les requêtes.
Contrôle d'accès HTTP (CORS)
Le partage de ressources cross-origin (CORS) est un mécanisme qui utilise des en-têtes HTTP supplémentaires pour permettre à un agent utilisateur d'obtenir la permission d'accéder à des ressources sélectionnées depuis un serveur sur une origine (domaine) différente de celle du site actuellement utilisé.
Partage de ressources cross-origin (CORS)
Comprenons l'image ci-dessus pour mieux comprendre CORS.
Requête Same Origin: Nous avons ouvert domain-a.com, où nous demandons une image bleue hébergée sur le serveur web domain-a.com. Puisque nous effectuons nos requêtes dans le même domaine, cela s'appelle une requête same-origin.
Requête Cross Origin: Nous avons ouvert domain-a.com, où nous demandons une image rouge hébergée sur le serveur web domain-b.com. Puisque nous effectuons nos requêtes dans des domaines différents, cela s'appelle une requête Cross-origin.
Requêtes simples
Ce sont des requêtes qui n'envoient pas leur première requête avec la méthode OPTIONS. Elles ne sont envoyées qu'une seule fois.
Cela soulève sûrement la question, pourquoi la première requête aurait-elle la méthode OPTIONS si nous ne l'envoyons pas, veuillez patienter, cela sera expliqué ci-dessous dans la section préflight ☺
Mais avant cela, comprenons quels sont les points qui rendent une requête simple.
Les seules méthodes autorisées dans une requête simple sont:
En dehors des en-têtes définis automatiquement par l'agent utilisateur (par exemple, connection, User-Agent, ou l'un des autres en-têtes avec des noms définis dans la spécification Fetch comme un "nom d'en-tête interdit"), les seuls en-têtes qui sont autorisés à être définis manuellement sont ceux que la spécification Fetch définit comme étant un "en-tête de requête CORS-safelisted", qui sont:
Accept
Accept-Language
Content-Language
Content-Type
DPR
Downlink
Save-Data
Viewport-Width
Width
Les seules valeurs autorisées pour l'en-tête Content-Type sont:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Aucun écouteur d'événements n'est enregistré sur un objet XMLHttpRequestUpload utilisé dans la requête.
Aucun objet ReadableStream n'est utilisé dans la requête.
Requêtes préflight
Une requête préflight est un type de requête qui envoie une requête HTTP par la méthode OPTIONS à la ressource sur l'autre domaine, afin de déterminer si la requête réelle est sûre à envoyer. Les requêtes cross-site sont préflightées de cette manière car elles peuvent avoir des implications sur les données utilisateur. Cela est évident d'après les captures d'écran ci-dessus.
Pour des requêtes comme PUT, DELETE, PATCH, etc., des requêtes préflight sont envoyées.
Le diagramme ci-dessous résume très bien son fonctionnement.
Image Courtesy html5rocks
Ce diagramme ouvre une porte à une toute nouvelle connaissance. Je ne peux m'empêcher d'apprécier à quel point il est bon!
Étrangement, même une requête GET a été observée avoir des préflights, ce qui dans mon cas était dû à la présence d'un en-tête personnalisé Authorization, ce qui peut être vu sur la capture d'écran ci-dessous
La requête Preflight est-elle mauvaise?
C'est une petite requête sans corps, mais je l'ai toujours ressentie comme une gêne. C'est toujours une requête, et chaque requête a un coût, peu importe la taille de cette requête, donc je recommande définitivement d'essayer d'éviter de tels cas.
Comment l'éviter?
Eh bien, la solution la plus simple est d'éviter CORS, essayez de garder nos ressources et API dans le même domaine. C'est vraiment aussi simple que cela.
Conclusion
Il est toujours bon d'être armé de connaissances sur le fonctionnement des requêtes. Même si le coût est très faible, cela compte toujours. Économiser de petites requêtes peut rendre notre application vraiment rapide à long terme. Eh bien, je crois en l'avenir, qui est rapide et furieux.
Suivez-moi sur twitter pour obtenir plus de mises à jour concernant les nouveaux articles et pour rester à jour dans les derniers développements frontend. Partagez également cet article sur twitter pour aider les autres à en savoir plus. Partager, c'est prendre soin ^_^
Quelques ressources utiles
Voici quelques liens qui ont inspiré cet article