Pourquoi ma politique CORS bloque-t-elle les requêtes provenant de \'https://example.com/\' avec une barre oblique finale ?

L'accès depuis l'origine 'https://example.com/' a été bloqué par la stratégie CORS : la réponse à la demande de contrôle en amont ne passe pas le contrôle de contrôle d'accès : c'est le cas pas de statut HTTP ok.

TL;DR

Les origines Web ne ne contiennent pas de chemin. Par conséquent, https://googledocs-clone-sbayrak.netlify.app/ n'est pas une origine Web valide. Supprimez cette barre oblique finale.

Plus de détails sur les origines Web de CORS

Aucune barre oblique finale n'est autorisée dans la valeur de l'en-tête d'origine

Selon le protocole CORS (spécifié dans la norme Fetch), les navigateurs ne définissent jamais l'en-tête de la requête Origin sur une valeur avec une barre oblique finale. Par conséquent, si une page sur https://googledocs-clone-sbayrak.netlify.app/whatever émet une requête d'origine croisée, l'en-tête Origin de cette requête contiendra

sans aucune barre oblique finale.

Comparaison octet par octet côté serveur

Vous utilisez Socket.IO, qui s'appuie sur le package cors Node.js. Ce package ne définira aucun Access-Control-Allow-Origin dans la réponse si l'origine de la requête ne correspond pas exactement à la valeur d'origine de votre configuration CORS (https://googledocs-clone-sbayrak.netlify.app/).

Putting It All Together

Évidemment,

est évalué à false, ce qui fait que le package cors ne définit aucun Access-Control-Allow-Origin en-tête dans la réponse, ce qui provoque l'échec de la vérification CORS dans votre navigateur, d'où l'erreur CORS que vous avez observée.

Exemple du Fetch Standard

Section 3.2.5 de le Fetch Standard fournit même un exemple éclairant de cette erreur :

et explique pourquoi cela provoque l'échec de la vérification CORS :

A l'origine sérialisée n'a pas de barre oblique finale.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!