ERR_HTTP2_PROTOCOL_ERROR ist die vage Meldung, und das ist selbst ein Hinweis

Eine Anfrage ist fehlgeschlagen. Es gibt keinen Statuscode, denn keine Antwort ist je angekommen. Und wenn Sie in Ihrem Access-Log nach der Anfrage suchen, die fehlgeschlagen ist, gibt es dort überhaupt keine Zeile für sie.

Diese Kombination ist die Signatur eines Fehlers unterhalb von HTTP, und ERR_HTTP2_PROTOCOL_ERROR ist die häufigste Art, wie Chrome einen meldet. Es lohnt sich zehn Minuten, denn fast alles, was darüber geschrieben ist, empfiehlt die gleiche Umleitung, und die Umleitung ist eine Diagnose, die Menschen für eine Heilung halten.

Was der Code wirklich sagt

Chromiums Liste der Netzwerkfehler, aus der diese Strings generiert werden, definiert es in sechs Worten:

Es gibt einen HTTP/2-Protokollfehler.

Das ist der ganze Eintrag. Die Nummer ist -337, und nichts darin nennt eine Ursache, eine Richtung oder eine Partei. Die String zu durchsuchen gibt Ihnen tausend Seiten Vermutung, denn die Quelle selbst vermutet auch.

Die sechs, die nicht vage sind, und warum das wichtig ist

Hier ist der Teil, den niemand erwähnt. Chromium hat nicht einen HTTP/2-Fehler. Es hat mehrere, und jeden anderen ist spezifisch:

• ERR_HTTP2_SERVER_REFUSED_STREAM, -351, das die Quelle ausführlich beschreibt: Der Server “lehnte die Anfrage ab, ohne sie zu verarbeiten” und sagte das, entweder mit einem GOAWAY-Frame mit Fehlercode NO_ERROR und einer Last-Stream-ID unterhalb dieser Anfrage oder ein RST_STREAM mit REFUSED_STREAM. Der Kommentar fügt das operative Detail hinzu: “Client KANN erneut versuchen (auf einer anderen Verbindung).”
• ERR_HTTP2_PING_FAILED, -352: “HTTP/2-Server hat nicht auf die PING-Nachricht geantwortet.”
• ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY, -360: “Transportsicherheit ist für die HTTP/2-Version unzureichend.”
• ERR_HTTP2_FLOW_CONTROL_ERROR, -361, ERR_HTTP2_FRAME_SIZE_ERROR, -362, und ERR_HTTP2_COMPRESSION_ERROR, -363.

Wenn Sie also -337 erhalten, anstatt einen davon, haben Sie etwas Echtes gelernt: es war kein abgelehnter Stream, kein totes Keepalive, kein Cipher-Problem, keine Flusskontrolle, keine Rahmengröße, keine Header-Kompression. ERR_HTTP2_PROTOCOL_ERROR ist das “keine der obigen” von HTTP/2, und die obigen sind sechs benannte Dinge, die Sie jetzt aufhören können zu untersuchen.

Das ist ein kleineres Ergebnis als eine Ursache, und es ist viel besser als nichts, was die Meldung allein zu bieten scheint.

Warum Ihre Logs leer sind

Der Grund, dass es keine Access-Log-Zeile gibt, steht in der Spezifikation, und es lohnt sich zu lesen, denn es erklärt auch, warum ein Nutzer mehrere Dinge auf einmal als fehlgeschlagen meldet.

RFC 9113 unterscheidet zwei Arten von Fehlern. “Ein Stream-Fehler ist ein Fehler, der einen bestimmten Stream betrifft und die Verarbeitung anderer Streams nicht beeinträchtigt.” Ein Verbindungsfehler ist das ganz andere: “jeder Fehler, der die weitere Verarbeitung der Frame-Schicht verhindert oder einen Verbindungszustand beschädigt.”

HTTP/2 multiplexiert. Eine Verbindung trägt viele Anfragen zur gleichen Zeit, also ein Verbindungsfehler schlägt nicht die Anfrage fehl, die ihn ausgelöst hat. Es schlägt jede Anfrage fehl, die auf dieser Verbindung in der Luft ist.

Was der Bericht sagt

Eine Seite halb geladen, einige Bilder fehlen und ein Formularabsend hat nichts getan. Drei getrennte Fehler, getrennt eingereicht

Was passiert ist

Ein Verbindungsfehler brachte alles zum Absturz, das in der Luft auf dieser Verbindung war, zur gleichen Zeit. Eine Ursache, drei Symptome, und kein Statuscode auf einem von ihnen

Und weil der Austausch nie als HTTP abgeschlossen wurde, gibt es nichts für Ihren Server zu protokollieren. Keine Methode, kein Pfad, kein Status. Der Nutzer sah etwas fehlschlag und Ihre Logs zeigen eine Lücke, wo es hätte sein sollen.

Was sicher wiederzuversuchen ist, was das Protokoll beantwortet

Das ist die Frage, die wichtig ist, wenn eine Zahlung oder eine Formularübermittlung in der Luft war, und sie hat eine echte Antwort, nicht ein Schulterzuckend.

RFC 9113 sagt, dass “ein Endpunkt, der auf einen Verbindungsfehler trifft, SOLLTE zunächst einen GOAWAY-Frame (Abschnitt 6.8) mit dem Stream-Identifikator des letzten Streams senden, das er erfolgreich von seinem Peer erhalten hat.”

Dieser Identifikator zieht eine Linie durch die Anfragen. Alles, das darüber nummeriert ist, wurde nicht empfangen, was bedeutet, es wurde nicht verarbeitet, was bedeutet, dass das erneute Versuchen nichts duplizieren kann. Das ist genau, warum Chromiums eigene Notiz auf einem abgelehnten Stream sagt, der Client kann auf einer anderen Verbindung erneut versuchen.

Das Fangen ist, dass diese Information für etwa eine Sekunde existiert, innerhalb des Browsers, und dann ist sie weg. Sie ist nicht in Ihrem Server-Log, denn die Frames, die sie trugen, sind unterhalb der Schicht, die Ihr Server protokolliert.

“HTTP/2 ausschalten” ist eine Diagnose, nicht eine Heilung

Der Rat, den Sie überall finden, ist, HTTP/2 auszuschalten und zu sehen, ob das Problem aufhört. Es ist guter Rat und es ist weit verbreitet missverstanden.

Wenn die Fehler aufhören, haben Sie gelernt, wo der Fehler lebt: etwas in der HTTP/2-Schicht zwischen diesem Nutzer und Ihnen misshandelt Frames. Sie haben nicht gelernt, dass HTTP/2 unzuverlässig ist, und Sie haben nichts behoben. Sie haben Multiplexing für jeden Besucher ausgeschaltet, um einen Bug einer Partei herumzuarbeiten.

Diese Partei ist normalerweise nicht Ihr Server. Die häufigen Ursachen sind die Dinge in der Mitte: ein Reverse Proxy oder Load Balancer mit seiner eigenen HTTP/2-Implementierung, eine CDN-Edge, Netzwerk-Equipment der Unternehmensgruppe, das TLS beendet und neu etabliert, und Sicherheitssoftware auf der Maschine des Nutzers, die das Gleiche tut. Jede davon spricht HTTP/2 in Ihrem Namen, und jede ist ein Ort, wo ein Frame falsch geformt werden kann, ohne dass jemand auf beiden Seiten etwas Falsches tut.

Das ist, warum dies oft ein Büro, ein Internet-Anbieter oder ein Antivirusprogramm betrifft, und niemand sonst.

Was Sie der Person fragen sollten, die es getroffen hat

Zwei Fragen, und die zweite ist mehr wert als sie aussieht.

Die exakte String aus der Konsole oder der Fehlerseite. ERR_HTTP2_PROTOCOL_ERROR und ERR_HTTP2_SERVER_REFUSED_STREAM sind verschiedene Probleme mit verschiedenen Antworten, und ein Bericht, der sagt “ein Netzwerkfehler” hat die einzige Unterscheidung weggeworfen, die kostenlos war.

Geschieht es auf einem anderen Netzwerk? Wenn es auf mobilen Daten aufhört, ist die Ursache zwischen Ihnen und dem Nutzer statt auf Ihrem Server, und Sie haben es auf Netzwerk-Equipment des Nutzers in einer Frage eingegrenzt. Dies ist der gleiche Test, der einen Corporate Proxy von einem echten Zertifikatproblem auf dem Bildschirm Verbindung ist nicht privat trennt, und es funktioniert hier aus dem gleichen Grund.

Was davon zu nehmen ist

Die Meldung ist vage, denn die Quelle ist vage, und das zu wissen hindert Sie daran, Bedeutung hinein zu lesen, die nicht da ist. Was es Ihnen sagt, ist alles, was es nicht ist, und sechs benannte Alternativen ist eine echte Eingrenzung.

Der Rest folgt, wo der Fehler sitzt. Es ist unterhalb von HTTP, also gibt es keinen Statuscode und oft keine Log-Zeile. Es ist ein Verbindungsfehler, also nimmt es mehrere Anfragen mit sich und kommt als mehrere Bug-Berichte an. Und das, das Ihnen sagen würde, ob ein Wiederholen sicher ist, ist ein Frame, den der Browser sah und Ihr Server nie tat.

Chromiums Liste dieser Fehler, mit der einzeiligen Definition von jedem, ist net_error_list.h, und das Protokoll selbst ist RFC 9113.