Ce que signifie ERR_BLOCKED_BY_CLIENT et pourquoi votre serveur ne l'a jamais vu

La propre liste des erreurs réseau de Chromium la décrit brièvement :

Le client a choisi de bloquer la requête.

Le mot qui porte le poids, c’est choisi. Rien n’a échoué. Aucun serveur n’était en panne, aucun nom n’a été non résolvable, aucun certificat n’était mauvais. Quelque chose s’exécutant sur la propre machine du visiteur a examiné une requête que votre page s’apprêtait à faire et a décidé qu’elle ne serait pas envoyée.

Ce qui signifie que votre serveur ne l’a jamais vue. Il n’y a aucune ligne dans votre journal d’accès, aucune entrée dans votre suivi d’erreurs, et rien à trouver de votre côté du tout, parce que du point de vue de votre infrastructure la requête n’existe pas.

Qui est le client

Habituellement une extension. Les bloqueurs de publicités et de traceurs sont le cas courant, et ils sont beaucoup plus largement installés que la plupart des équipes ne le supposent quand elles regardent leurs propres machines.

Mais la catégorie est plus large que cela. Un logiciel de point de terminaison d’entreprise filtre les requêtes avant qu’elles ne quittent la machine. Certains produits antivirus font la même chose. Une configuration de proxy d’entreprise peut refuser un hôte. Les paramètres du navigateur sur un appareil géré peuvent bloquer une catégorie entière. Tous ceux-ci produisent la même erreur, et aucun d’eux n’est quelque chose que la personne signalant le problème sait qu’elle a.

La seule chose qu’ils partagent, c’est qu’ils se trouvent entre votre code et le réseau, à l’intérieur de l’environnement de l’utilisateur, où vous n’avez ni visibilité ni contrôle.

Trois erreurs qui disent toutes bloqué

Chromium en a plusieurs, elles ne sont pas interchangeables, et la différence dépend entièrement de qui a effectué le blocage. Voici les trois qui valent la peine de connaître, avec les descriptions de la liste d’erreurs elle-même :

• ERR_BLOCKED_BY_CLIENT: « Le client a choisi de bloquer la requête. » Quelque chose sur la machine de l’utilisateur. Pas la vôtre, et pas celle de l’autre site.
• ERR_BLOCKED_BY_CSP: « La requête a été bloquée par une Content Security Policy. » Votre propre politique, ou celle qu’un proxy a ajoutée en chemin.
• ERR_BLOCKED_BY_RESPONSE: la réponse est arrivée en portant des exigences qui n’ont pas été satisfaites, comme X-Frame-Options, les vérifications d’ancêtres Content-Security-Policy ou Cross-Origin-Resource-Policy. Celle-ci est la décision de l’autre bout.

Trois erreurs, trois propriétaires : la machine de l’utilisateur, votre politique, leurs en-têtes. Seule celle du milieu est la vôtre à corriger, et c’est celle que les gens atteignent en dernier. Une quatrième famille se confond avec celles-ci assez souvent pour être aussi digne de séparation : une erreur CORS n’est pas un blocage du tout, c’est une réponse que le navigateur a récupérée et a alors refusé de remettre à votre code.

Ce que votre JavaScript voit, ce qui est presque rien

Voici la partie qui rend cela coûteux. Une requête bloquée n’arrive pas dans votre code en tant que « bloquée ».

fetch() rejette avec un TypeError, et MDN est explicite que c’est ce que vous obtenez pour une erreur réseau en général, « par exemple, parce que l’appareil n’a pas de connectivité ». Le même rejet couvre une URL mal formée, un appareil réellement hors ligne, et une requête qu’une extension a refusé d’envoyer. La promesse ne porte aucune raison, il n’y a donc rien dans le rejet pour les distinguer.

Il vaut la peine de se souvenir de ce qui ne rejette pas alors que vous êtes ici : un statut d’erreur HTTP ne le fait pas. Un 404 ou un 504 se résout normalement et vous laisse vérifier response.ok. Donc l’échec qui produit le moins d’informations dans votre code est celui où la requête n’a jamais quitté la machine, et les échecs qui produisent le plus sont ceux que votre serveur a gérés.

Si vous voulez la distinction, le navigateur l’a. Le panneau réseau montre la requête avec l’erreur réseau contre elle, et chrome://net-export la capture. Les deux se trouvent sur l’ordinateur de l’utilisateur, ce qui est le problème dont parle tout cet article.

Pourquoi c’est si difficile à reproduire

Vous ne pouvez pas la reproduire, par construction, parce que la cause n’est pas dans votre système. Elle est dans une configuration qui existe sur une machine, choisie par quelqu’un qui ne se souvient peut-être pas l’avoir choisie, et tout à fait probablement installée par son employeur.

La boucle va donc : un utilisateur signale que l’enregistrement ne fait rien, vous ouvrez la page, l’enregistrement fonctionne, vous fermez le ticket. L’utilisateur ne se trompe pas et vous non plus. La différence, c’est une liste d’hôtes bloqués que vous ne pouvez pas voir.

Leur demander de désactiver les extensions fonctionne parfois et est un mauvais instrument. Cela demande à une personne d’expérimenter sur son propre navigateur en votre nom, cela ne trouve que le cas d’extension, et un appareil géré ne les laissera pas le faire du tout.

Le journal réseau est ce qui le règle, parce que la requête qui a été refusée s’y trouve avec l’erreur contre elle. Cela transforme « l’enregistrement ne fait rien » en « cette requête à cet hôte n’a jamais quitté leur machine », ce qui est une conversation différente et généralement une courte.

Quoi en faire

Attendez-vous à cela sur n’importe quoi qui ressemble à du suivi. Les hôtes avec analytics, metrics, telemetry, beacon ou ads dans le nom sont bloqués par défaut par les listes communes. Tout comme les chemins. Si votre propre signalement d’erreurs vit sur un tel hôte, les rapports à ce sujet sont ceux que vous ne recevrez jamais.

Ne laissez pas une requête bloquée casser la page. Un appel d’analytics bloqué ne devrait pas arrêter la soumission d’un formulaire. Séparez la requête qui importe de celle qui est agréable à avoir, et laissez la deuxième échouer silencieusement.

Traitez l’absence de données comme des données. Moins d’événements d’un sous-ensemble d’utilisateurs est l’un des rares signaux que ceci laisse derrière, et cela se lit comme une semaine tranquille plutôt que comme une faute.

En un paragraphe

ERR_BLOCKED_BY_CLIENT signifie que quelque chose sur la machine du visiteur, habituellement une extension et parfois le logiciel de son employeur, a décidé que votre requête ne serait pas envoyée. Votre serveur ne l’a jamais vue, fetch la signale comme le même TypeError qu’il utilise pour un appareil hors ligne, et le seul enregistrement se trouve sur un ordinateur que vous n’avez pas. Ce n’est pas la même chose qu’un blocage de politique que vous possédez ou un en-tête que l’autre bout a envoyé, et distinguer ces trois est la majeure partie du travail.