Was ERR_BLOCKED_BY_CLIENT bedeutet und warum Ihr Server es nie sah

Chromiums eigene Liste mit Netzwerkfehlern beschreibt diesen in einem einzigen Satz:

Der Client hat sich entschieden, die Anfrage zu blockieren.

Das Wort mit Gewicht ist entschieden. Nichts ist gescheitert. Kein Server war down, kein Name konnte nicht aufgelöst werden, kein Zertifikat war falsch. Etwas, das auf dem Rechner des Besuchers läuft, hat sich eine Anfrage angesehen, die Ihre Seite gerade senden wollte, und entschieden, dass diese nicht gemacht würde.

Was bedeutet, dass Ihr Server sie nie sah. Es gibt keine Zeile in Ihrem Zugriffprotokoll, keinen Eintrag in Ihrem Error-Tracker und nichts, das Sie auf Ihrer Seite finden könnten, denn aus Sicht Ihrer Infrastruktur existiert die Anfrage nicht.

Wer der Client ist

Normalerweise eine Erweiterung. Ad- und Tracker-Blocker sind der häufige Fall, und sie sind weit verbreiteter installiert, als die meisten Teams vermuten, wenn sie auf ihre eigenen Maschinen schauen.

Aber die Kategorie ist breiter als das. Enterprise-Endpoint-Software filtert Anfragen, bevor sie die Maschine verlassen. Manche Antivirus-Produkte tun dasselbe. Eine Corporate-Proxy-Konfiguration kann einen Host ablehnen. Browser-Einstellungen auf einem verwalteten Gerät können eine Kategorie ganz blockieren. All das produziert denselben Fehler, und keines davon ist etwas, das die Person, die das Problem meldet, weiß, dass sie es hat.

Das eine, das sie alle gemeinsam haben, ist, dass sie zwischen Ihrem Code und dem Netzwerk sitzen, in der Umgebung des Benutzers, wo Sie keine Sichtbarkeit und keine Kontrolle haben.

Drei Fehler, die alle “blockiert” sagen

Chromium hat mehrere, sie sind nicht austauschbar, und der Unterschied dreht sich ganz um die Frage, wer blockiert hat. Dies sind die drei, die wissen wert sind, mit den Beschreibungen aus der Fehlerliste selbst:

• ERR_BLOCKED_BY_CLIENT: “Der Client hat sich entschieden, die Anfrage zu blockieren.” Etwas auf der Maschine des Benutzers. Nicht Ihre, nicht die des anderen Sites.
• ERR_BLOCKED_BY_CSP: “Die Anfrage wurde durch eine Content Security Policy blockiert.” Ihre eigene Policy, oder eine, die ein Proxy auf dem Weg hinzugefügt hat.
• ERR_BLOCKED_BY_RESPONSE: Die Antwort kam mit Anforderungen an, die nicht erfüllt wurden, wie X-Frame-Options, Content-Security-Policy Ancestor-Überprüfungen oder Cross-Origin-Resource-Policy. Das ist die Entscheidung der anderen Seite.

Drei Fehler, drei Besitzer: die Maschine des Benutzers, Ihre Policy, deren Header. Nur die mittlere ist Ihre, um sie zu beheben, und sie ist diejenige, auf die Leute zuletzt greifen. Eine vierte Familie wird mit diesen oft genug verwechselt, um auch separiert zu werden: Ein CORS-Fehler ist überhaupt kein Block, es ist eine Antwort, die der Browser abgerufen und dann Ihrem Code verweigert hat.

Was Ihr JavaScript sieht, was fast nichts ist

Hier ist der Teil, der das teuer macht. Eine blockierte Anfrage kommt nicht in Ihrem Code als “blockiert” an.

fetch() lehnt mit einem TypeError ab, und MDN ist explizit, dass dies das ist, das Sie für einen Netzwerkfehler im Allgemeinen bekommen, “zum Beispiel, weil das Gerät keine Verbindung hat”. Dieselbe Ablehnung deckt eine falsch geformte URL, ein wirklich offline Gerät und eine Anfrage ab, die eine Erweiterung sich geweigert hat zu senden. Das Promise trägt keinen Grund, also gibt es in der Ablehnung nichts, das diese auseinanderhalten könnte.

Es lohnt sich zu erinnern, was nicht ablehnt, während Sie hier sind: Ein HTTP-Fehlerstatus tut es nicht. Ein 404 oder ein 504 wird normal aufgelöst und lässt Sie response.ok überprüfen. So ist der Fehler, der die wenigsten Informationen in Ihrem Code produziert, der, wo die Anfrage nie die Maschine verließ, und die Fehler, die die meisten produzieren, sind diejenigen, die Ihr Server bearbeitet hat.

Wenn Sie den Unterschied wollen, hat der Browser ihn. Das Netzwerk-Panel zeigt die Anfrage mit dem Netzwerkfehler dagegen, und chrome://net-export erfasst es. Beide von diesen sind auf dem Computer des Benutzers, was das Problem dieses ganzen Artikels ist.

Warum es so schwer zu reproduzieren ist

Sie können es nicht reproduzieren, durch Konstruktion, denn die Ursache ist nicht in Ihrem System. Es ist in einer Konfiguration, die auf einer Maschine existiert, gewählt von jemandem, der sich möglicherweise nicht erinnert, das gewählt zu haben, und ganz möglicherweise von ihrem Arbeitgeber installiert.

So geht die Schleife: Ein Benutzer meldet, dass das Speichern nichts tut, Sie öffnen die Seite, das Speichern funktioniert, Sie schließen das Ticket. Der Benutzer irrt nicht und Sie auch nicht. Der Unterschied ist eine Liste blockierter Hosts, die Sie nicht sehen können.

Sie zu bitten, Erweiterungen zu deaktivieren, funktioniert manchmal und ist ein schlechtes Instrument. Es bittet eine Person, auf ihrem eigenen Browser in Ihrem Namen zu experimentieren, es findet nur den Erweiterungsfall, und ein verwaltetes Gerät wird es ihnen nicht erlauben, das zu tun.

Das Netzwerkprotokoll ist das, was es klärt, denn die Anfrage, die sich geweigert wurde, ist drin mit dem Fehler dagegen. Das verwandelt “Speichern tut nichts” in “diese Anfrage an diesen Host verließ niemals ihren Rechner”, was ein anderes Gespräch ist und normalerweise ein kurzes.

Was zu tun ist

Erwarten Sie es auf Alles, das wie Tracking aussieht. Hosts mit Analytics, Metriken, Telemetrie, Beacon oder Ads im Namen werden von Standard-Listen blockiert. Ebenso wie Pfade. Wenn Ihr eigenes Error-Reporting auf solch einem Host lebt, sind die Berichte darüber diejenigen, die Sie nie erhalten werden.

Lassen Sie eine blockierte Anfrage nicht die Seite brechen. Ein blockierter Analytics-Aufruf sollte nicht das Senden eines Formulars stoppen. Trennen Sie die Anfrage, die wichtig ist, von der Anfrage, die nett zu haben ist, und lassen Sie die zweite stillschweigend scheitern.

Behandeln Sie das Fehlen von Daten als Daten. Weniger Ereignisse von einer Teilmenge von Benutzern ist eines der wenigen Signale, das das hinterlässt, und es liest sich als eine ruhige Woche statt als ein Fehler.

In einem Absatz

ERR_BLOCKED_BY_CLIENT bedeutet, dass etwas auf der Maschine des Besuchers, normalerweise eine Erweiterung und manchmal die Software ihres Arbeitgebers, sich entschieden hat, dass Ihre Anfrage nicht gesendet wird. Ihr Server sah sie nie, fetch meldet sie als denselben TypeError, den es für ein offline Gerät benutzt, und die einzige Aufzeichnung ist auf einem Computer, den Sie nicht haben. Es ist nicht dasselbe wie ein Policy-Block, den Sie besitzen, oder ein Header, den die andere Seite gesendet hat, und diese drei auseinanderzuhalten ist der größte Teil der Arbeit.