Worum geht es im net :: ERR_HTTP2_PROTOCOL_ERROR?

Ich arbeite derzeit an einer Website, die einen net::ERR_HTTP2_PROTOCOL_ERROR 200Fehler in Google Chrome auslöst . Ich bin mir nicht sicher, was genau diesen Fehler hervorrufen kann. Ich habe gerade bemerkt, dass er nur beim Zugriff auf die Website in HTTPS angezeigt wird. Ich kann nicht 100% sicher sein, dass es verwandt ist, aber es sieht so aus, als würde es verhindern, dass Javascript richtig ausgeführt wird.

Das folgende Szenario tritt beispielsweise auf:

1. Ich greife in HTTPS auf die Website zu

2. Mein über https://publish.twitter.com integrierter Twitter-Feed wird überhaupt nicht geladen

3. Ich kann in der Konsole den ERR_HTTP2_PROTOCOL_ERROR feststellen

4. Wenn ich den Code zum Laden des Twitter-Feeds entferne, bleibt der Fehler bestehen

5. Wenn ich über HTTP auf die Website zugreife, wird der Twitter-Feed angezeigt und der Fehler verschwindet

Google Chrome ist der einzige Webbrowser, der den Fehler auslöst: Es funktioniert sowohl unter Edge als auch unter Firefox. (NB: Ich habe es mit Safari versucht und habe einen ähnlichen kcferrordomaincfnetwork 303Fehler.)

Ich habe mich gefragt, ob dies mit dem vom Server zurückgegebenen Header zusammenhängen könnte, da der Fehler diese '200'-Erwähnung enthält und eine 404/500-Seite nichts auslöst.

Die Sache ist, dass der Fehler überhaupt nicht dokumentiert ist. Die Google-Suche liefert mir nur sehr wenige Ergebnisse. Außerdem habe ich festgestellt, dass es in den neuesten Google Chrome-Versionen angezeigt wird. Der Fehler tritt nicht in Version 64.X auf, sondern in Version 75 + (unabhängig vom Betriebssystem; ich arbeite auf einem Mac tho).

Jeder Hinweis an dieser Stelle zu untersuchen wäre gerne dankbar!

Danke im Voraus.

Tristan

Bearbeiten 1: Kann mit der Website OK in Firefox, aber nicht in Safari (kCFErrorDomainCFNetwork-Fehler 303) oder Chrome (net :: ERR_SPDY_PROTOCOL_ERROR) zusammenhängen.

Edit 2: Ergebnisse weiterer Untersuchungen sind folgende:

• Der Fehler wird nicht auf genau derselben Seite angezeigt, wenn der Server 404 anstelle von 2XX zurückgibt
• Fehler tritt nicht lokal mit einem HTTPS-Zertifikat auf
• Der Fehler tritt auf einem anderen Server auf (beide sind OVHs), der ein anderes Zertifikat verwendet
• Fehler tritt unabhängig von der verwendeten PHP-Version von 5.6 bis 7.3 auf (verwendetes Framework: Cakephp 2.10)

Bearbeiten 3: Wie angefordert, ist unten der zurückgegebene Header für die fehlerhafte Ressource, die die gesamte Webseite darstellt. Selbst wenn der Fehler auf jeder Seite mit einem HTTP-Header 200 ausgelöst wird, werden diese Seiten immer im Browser des Clients geladen, aber manchmal fehlt ein Element (in meinem Beispiel der externe Twitter-Feed). Jedes andere Asset auf der Registerkarte Netzwerk hat eine Erfolgsrendite, mit Ausnahme des gesamten Dokuments.

Google Chrome-Header (mit Fehler):

Firefox-Header (ohne Fehler):

Eine curl --head --http2Anforderung in der Konsole gibt den folgenden Erfolg zurück:

HTTP/2 200 
date: Fri, 04 Oct 2019 08:04:51 GMT
content-type: text/html; charset=UTF-8
content-length: 127089
set-cookie: SERVERID31396=2341116; path=/; max-age=900
server: Apache
x-powered-by: PHP/7.2
set-cookie: xxxxx=0919c5563fc87d601ab99e2f85d4217d; expires=Fri, 04-Oct-2019 12:04:51 GMT; Max-Age=14400; path=/; secure; HttpOnly
vary: Accept-Encoding

Bearbeiten 4: Der Versuch, mit den Tools chrome: // net-export / und https://netlog-viewer.appspot.com tiefer zu gehen, sagt mir, dass die Anforderung mit einem RST_STREAM endet:

t=123354 [st=5170]    HTTP2_SESSION_RECV_RST_STREAM
                      --> error_code = "2 (INTERNAL_ERROR)"
                      --> stream_id = 1

Für das, was ich in diesem anderen Beitrag gelesen habe : " Wenn der Client in HTTP / 2 die Anforderung abbrechen möchte, sendet er ein RST_STREAM. Wenn der Server ein RST_STREAM empfängt, hört er auf, DATA-Frames an den Client zu senden, wodurch die Antwort gestoppt wird." (oder der Download). Die Verbindung kann weiterhin für andere Anforderungen verwendet werden, und Anforderungen / Antworten, die gleichzeitig mit der abgebrochenen angefordert wurden, können fortgesetzt werden. [...] Es ist möglich, dass RST_STREAM zu dem Zeitpunkt abläuft Wenn der Client an den Server gesendet wird, wird der gesamte Inhalt der Anforderung übertragen und kommt beim Client an, wodurch er verworfen wird. Bei großen Antwortinhalten kann das Senden eines RST_STREAM jedoch eine gute Chance haben, vor dem Ganzen am Server anzukommen Antwortinhalte werden gesendet und sparen daher Bandbreite. "

Das beschriebene Verhalten ist das gleiche wie das, das ich beobachten kann. Aber das würde bedeuten, dass der Browser der Schuldige ist, und dann würde ich nicht verstehen, warum es auf zwei identischen Seiten passiert, von denen eine einen 200-Header und die andere einen 404-Header hat (dasselbe gilt, wenn ich JS deaktiviere).

Einige Wochen lang ärgerte mich auch dieser "Bug":

net :: ERR_HTTP2_PROTOCOL_ERROR 200

In meinem Fall trat es bei Bildern auf, die von PHP generiert wurden.

Es war auf einer header()Ebene, und insbesondere in dieser Hinsicht:

header ('Content-Length:'. Filesize($cache_file));

Es hat offensichtlich nicht die genaue Größe zurückgegeben, also habe ich es gelöscht und jetzt funktioniert alles einwandfrei.

Daher überprüft Chrome die Richtigkeit der über die Header übertragenen Daten. Wenn diese nicht übereinstimmen, schlägt dies fehl.

BEARBEITEN

Ich habe herausgefunden, warum content-lengthvia filesizefalsch berechnet wurde: Die GZIPKomprimierung ist für die PHP-Dateien aktiv. Wenn Sie also die betreffende Datei ausschließen, wird das Problem behoben. Geben Sie diesen Code ein in .htaccess:

SetEnvIfNoCase Request_URI ^ / thumb.php no-gzip -vary

Es funktioniert und wir behalten den Header Content-length.

Ich habe nicht herausgefunden, was genau passiert ist, aber ich habe eine Lösung gefunden.

Das CDN-Merkmal von OVH war der Schuldige. Ich hatte es auf meinem Host-Dienst installiert, aber für meine Domain deaktiviert, weil ich es nicht brauchte.

Irgendwie funktioniert alles, wenn ich es aktiviere.

Ich denke, es zwingt Apache, das HTTP2-Protokoll zu verwenden, aber ich verstehe nicht, dass in jedem meiner Header tatsächlich eine HTTP2-Erwähnung enthalten war, was vermutlich bedeutet, dass der Server mit dem richtigen Protokoll geantwortet hat.

Die Lösung für meinen speziellen Fall bestand also darin, die CDN-Option für alle betroffenen Domänen zu aktivieren.

Wenn jemand besser versteht, was hier hätte passieren können, können Sie gerne Erklärungen abgeben.

Ich bin darauf gestoßen, weil der http2-Server die Verbindung geschlossen hat, als er eine große Antwort an Chrome gesendet hat .

Warum? Da es sich nur um eine Einstellung des http2-Servers mit dem Namen WriteTimeout handelt .

In meinem Fall war es - kein Speicherplatz mehr auf dem Webserver.

Ich hatte ein ähnliches Problem: Ich habe ERR_HTTP2_PROTOCOL_ERROR für eine der HTTP-GET-Anforderungen erhalten.

Ich habe festgestellt, dass das Chrome-Update aussteht, daher habe ich den Chrome-Browser auf die neueste Version aktualisiert und der Fehler wurde beim nächsten Neustart des Browsers behoben.

Ich hatte dieses Problem, als ich einen Nginx-Server hatte, der die node-js-Anwendung der Außenwelt aussetzte. Der Nginx hat die Datei (css, js, ...) gzipmit Chrome komprimiert und mit Chrome sah sie genauso aus.

Das Problem wurde gelöst, als wir feststellten, dass der Node-JS-Server den Inhalt auch mit gzip komprimiert. In gewisser Weise führt diese doppelte Komprimierung zu diesem Problem. Das Abbrechen der Node-JS-Komprimierung hat das Problem behoben.

Dieser Fehler wird derzeit behoben: https://chromium-review.googlesource.com/c/chromium/src/+/2001234

Aber es hat mir geholfen, die Nginx-Einstellungen zu ändern:

• gzip einschalten;
• add_header 'Cache-Control' 'No-Store, No-Cache, Must-Revalidate, Proxy-Revalidate, Max-Age = 0';
• verfällt;

In meinem Fall fungiert Nginx als Reverse-Proxy für die Node.js-Anwendung.

Dies ist mir passiert, als ich einen neuen Domainnamen registriert habe, z. B. "neu" für example.com (new.example.com). Der Name konnte für ein paar Stunden nicht vorübergehend an meinem Standort aufgelöst werden, während er im Ausland aufgelöst werden konnte. Also habe ich einen Proxy verwendet, um die Website zu testen, auf der ich net::ERR_HTTP2_PROTOCOL_ERRORin der Chrome-Konsole einige AJAX-Beiträge gesehen habe. Stunden später, als der Name lokal entfernt werden konnte, verschwand dieser Fehler einfach.

Ich denke, der Grund für diesen Fehler ist, dass AJAX-Anfragen nicht von meinem Proxy umgeleitet wurden, sondern nur eine Website besuchen, die von meinem lokalen DNS-Resolver nicht behoben wurde.

Ich bin mehrmals auf diesen Fehler gestoßen, weil große Ressourcen (größer als 3 MB) vom Server auf den Client übertragen wurden.

Ich habe das gleiche Problem (asp, c # - HttpPostedFileBase) beim Posten einer Datei, die größer als 1 MB war (obwohl die Anwendung keine Einschränkung für die Dateigröße hat), für mich hat die Vereinfachung der Modellklasse geholfen. Wenn Sie dieses Problem haben, versuchen Sie, einige Teile des Modells zu entfernen, und prüfen Sie, ob es in irgendeiner Weise hilfreich ist. Klingt seltsam, hat aber für mich funktioniert.

Ich habe dieses Problem seit der letzten Woche, als ich versucht habe, DELETE-Anfragen über AJAX an meinen PHP-Server zu senden. Ich habe kürzlich meinen Hosting-Plan aktualisiert, bei dem ich jetzt ein SSL-Zertifikat auf meinem Host habe, in dem die PHP- und JS-Dateien gespeichert sind. Seit dem Hinzufügen eines SSL-Zertifikats tritt dieses Problem nicht mehr auf. Ich hoffe, das hilft bei diesem seltsamen Fehler.

Ich war auch mit diesem Fehler konfrontiert und glaube, dass es mehrere Gründe dafür geben kann. Meins war, ARR wurde abgelaufen.

In meinem Fall hat der Browser eine Anfrage an eine Reverse-Proxy-Site gesendet, auf der ich meine Umleitungsregeln festgelegt habe, und diese Proxy-Site fordert schließlich die tatsächliche Site an. Bei großen Datenmengen dauerte es nun mehr als 2 Minuten und 5 Sekunden, und das Zeitlimit für das Routing von Anwendungsanforderungen für meinen Server wurde auf 2 Minuten festgelegt. Ich habe dies behoben, indem ich das ARR-Zeitlimit wie folgt erhöht habe: 1. Gehen Sie zu IIS. 2. Klicken Sie auf den Servernamen. 3. Klicken Sie im mittleren Bereich auf Routing-Cache für Anwendungsanforderungen. 4. Klicken Sie im rechten Bereich auf Server-Proxy-Einstellungen. 5. Erhöhen Sie das Zeitlimit. 6 Klicken Sie auf Übernehmen

In unserem Fall war der Grund ein ungültiger Header. Wie in Edit 4 erwähnt:

• Nimm die Protokolle
• Wählen Sie im Viewer Ereignisse
• wählte HTTP2_SESSION

Suchen Sie nach etwas Ähnlichem:

HTTP2_SESSION_RECV_INVALID_HEADER

-> error = "Ungültiges Zeichen im Headernamen."

-> header_name = " charset = utf-8 "

Mein Team hat dies in einer einzelnen Javascript-Datei gesehen, die wir bereitgestellt haben. Jede andere Datei hat gut funktioniert. Wir wechselten von http2zurück zu http1.1und dann entweder net::ERR_INCOMPLETE_CHUNKED_ENCODINGoder ERR_CONTENT_LENGTH_MISMATCH. Letztendlich stellten wir fest, dass es einen Unternehmensfilter (Trustwave) gab, der fälschlicherweise einen "Infoleak" erkannte (wir vermuten, dass in unserer Datei / unserem Dateinamen etwas entdeckt wurde, das einer Sozialversicherungsnummer ähnelte). Durch die Optimierung dieses Filters durch das Unternehmen wurden unsere Probleme behoben.

Dieses Problem trat auf Seiten mit langen Base64-Zeichenfolgen auf. Das Problem tritt auf, weil wir CloudFlare verwenden.

Details: https://community.cloudflare.com/t/err-http2-protocol-error/119619 .

Schlüsselabschnitt aus dem Forumsbeitrag:

Nach weiteren Tests auf Inkognito-Registerkarten in mehreren Browsern und anschließenden Änderungen am Code von einem BASE64 zu einem echten PNG-Bild ist das Problem in keinem Browser erneut aufgetreten. Die PNG-Datei hatte ungefähr 500 KB, bevor sie zu einer Base64 wurde. Daher hat CloudFlare Probleme mit großen Textzeilen in derselben Zeile (da base64 eine lange Zeichenfolge ist) als Proxy zwischen der Domäne und dem Heroku. Wie bereits erwähnt, ist das direkte Aufrufen der Heroku-URL auch nie aufgetreten.

Der temporäre Hack besteht darin, HTTP / 2 in CloudFlare zu deaktivieren.

Ich hoffe, jemand anderes kann eine bessere Lösung entwickeln, bei der HTTP / 2 in CloudFlare nicht deaktiviert werden muss.