Waar gaat het net::ERR_HTTP2_PROTOCOL_ERROR over?

Ik werk momenteel aan een website die een net::ERR_HTTP2_PROTOCOL_ERROR 200-fout veroorzaakt in Google Chrome. Ik weet niet precies wat deze fout kan veroorzaken, ik heb zojuist gemerkt dat het alleen tevoorschijn komt bij toegang tot de website in HTTPS. Ik kan er niet 100% zeker van zijn dat het gerelateerd is, maar het lijkt erop dat het JavaScript verhindert om correct uit te voeren.

Bijvoorbeeld het volgende scenario gebeurt:

  1. Ik ga naar de website via HTTPS

  2. Mijn Twitter-feed geïntegreerd via https://publish.twitter.comwordt niet geladen op alle

  3. Ik zie in de console de ERR_HTTP2_PROTOCOL_ERROR

  4. Als ik de code verwijder om de Twitter-feed te laden, blijft de fout bestaan

  5. Als ik de website in HTTP benader, verschijnt de Twitter-feed en verdwijnt de fout

Google Chrome is de enige webbrowser die de fout veroorzaakt: het werkt goed op zowel Edge als Firefox.
(NB: ik heb het geprobeerd met Safari en ik heb een soortgelijke kcferrordomaincfnetwork 303-fout)

Ik vroeg me af of het te maken kan hebben met de header die door de server wordt geretourneerd, aangezien er een ‘200’-vermelding in de fout staat en een 404/500-pagina niets activeert.

Het probleem is dat de fout helemaal niet is gedocumenteerd. Zoeken op Google geeft me heel weinig resultaten. Bovendien merkte ik dat het voorkomt in zeer recente Google Chrome-releases; de fout verschijnt niet op v.64.X, maar wel op v.75+ (ongeacht het besturingssysteem; ik werk op Mac).


Kan gerelateerd zijn aan Website OK in Firefox maar niet in Safari (kCFErrorDomainCFNetwork error 303) noch Chrome (net::ERR_SPDY_PROTOCOL_ERROR)


Bevindingen van verder onderzoek zijn de volgende:

  • fout verschijnt niet op exact dezelfde pagina als de server 404 retourneert in plaats van 2XX
  • fout verschijnt niet lokaal met een HTTPS-certificaat
  • fout verschijnt op een andere server (beide zijn van OVH), die een ander certificaat gebruikt
  • fout treedt op ongeacht welke PHP-versie wordt gebruikt, van 5.6 tot 7.3 (gebruikt framework: Cakephp 2.10)

Zoals gevraagd, is hieronder de geretourneerde header voor de falende bron, de hele webpagina. Zelfs als de fout wordt geactiveerd op elke pagina met een HTTP-header 200, worden die pagina’s altijd geladen in de browser van de klant, maar soms ontbreekt er een element (in mijn voorbeeld de externe Twitter-feed). Elk ander item op het tabblad Netwerk heeft een succesrendement, behalve het hele document zelf.

Google Chrome-header (met fout):

Firefox-header (zonder fout):

Een curl --head --http2-verzoek in de console geeft het volgende succes:

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

Proberen dieper te gaan met de chrome://net-export/ en https://netlog-viewer.appspot .comtools vertelt me dat het verzoek eindigt met een RST_STREAM :

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

Voor wat ik heb gelezen in dit andere bericht, “In HTTP /2, als de client het verzoek wil afbreken, stuurt het een RST_STREAM. Wanneer de server een RST_STREAM ontvangt, stopt het met het verzenden van DATA-frames naar de client, waardoor het antwoord (of de download) stopt. De verbinding is nog steeds bruikbaar voor andere verzoeken en verzoeken/antwoorden die gelijktijdig waren met degene die is afgebroken, kunnen doorgaan.
[…]
Het is mogelijk dat tegen de tijd dat de RST_STREAM van de client naar de server reist, de hele inhoud van het verzoek onderweg is en bij de client aankomt, die het zal weggooien. Voor grote responsinhoud kan het verzenden van een RST_STREAM echter een goede kans hebben om op de server aan te komen voordat de hele responsinhoud is verzonden, en daarom bandbreedte besparen.

Het beschreven gedrag is hetzelfde als het gedrag dat ik kan waarnemen. Maar dat zou betekenen dat de browser de boosdoener is, en dan zou ik niet begrijpen waarom het gebeurt op twee identieke pagina’s waarvan de ene een 200-header heeft en de andere een 404 (hetzelfde geldt als ik JS uitschakel).


Antwoord 1, autoriteit 100%

In mijn geval was het – geen schijfruimte meer op de webserver.


Antwoord 2, autoriteit 43%

Ik ben eindelijk in staat om deze fout op te lossen na het onderzoeken van sommige dingen die ik dacht dat de fout voor 24 fouten veroorzaakt. Ik heb alle pagina’s op het web bezocht. En ik ben blij om te zeggen dat ik de oplossing heb gevonden.
Als u NGINX gebruikt, stelt u gzip in op Uit en voeg proxy_max_temp_file_size 0;in het serverblok zoals ik hieronder heb getoond.

server {
  ...
  ...
  gzip off;
  proxy_max_temp_file_size 0;
  location / {
    proxy_pass http://127.0.0.1:3000/;
  ....

Waarom? Want wat er daadwerkelijk gebeurt, werden alle inhoud twee keer gecomprimeerd en dat willen we niet, toch?!


3, Autoriteit 40%

Gedurende enkele weken was ik ook geïrriteerd door deze “bug”:

net :: ERR_HTTP2_PROTOCOL_ERROR 200

In mijn geval gebeurde het op afbeeldingen die door PHP worden gegenereerd.

het was op header()niveau, en over deze in het bijzonder:

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

Het heeft duidelijk niet de exacte grootte teruggegeven, dus ik heb het verwijderd en alles werkt nu goed.

Dus chroom controleert de nauwkeurigheid van de gegevens die via de headers worden verzonden en als deze niet overeenkomt, mislukt het.

Bewerken

Ik heb gevonden waarom content-lengthVia filesizewerd geërceerd: de GZIPCompressie is actief op de PHP-bestanden, dus exclusief het bestand in kwestie zal het probleem oplossen. Zet deze code in de .htaccess:

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

Het werkt en we houden de koptekst content-length.


4, Autoriteit 24%

Ik heb een soortgelijk probleem ervaren, ik kreeg ERR_HTTP2_PROTOCOL_Error op een van de HTTP-aanvraag.

Ik heb gemerkt dat de Chrome-update in behandeling was, dus ik heb de Chrome-browser bijgewerkt naar de nieuwste versie en de fout is de volgende keer gewenst toen ik de browser herstelde.


5, Autoriteit 14%

Ik had dit probleem bij het hebben van een NGGINX-server die de Node-JS-applicatie blootstelt aan de externe wereld. De NGINX maakte het bestand (CSS, JS, …) gecomprimeerd met GZIPen met chroom leek het op hetzelfde.

Het probleem opgelost toen we vonden dat de Node-JS-server ook de inhoud met GZIP wordt gecomprimeerd. In wat, deze dubbele compressie leidt tot dit probleem. Het annuleren van knooppunt-JS-compressie opgelost het probleem.


6, Autoriteit 12%

Ik heb dit tegengekomen omdat de HTTP2-server de verbinding sloot bij het verzenden van een grote reactie op het chroom.

Waarom?
Omdat het slechts een instelling is van de HTTP2-server, genaamd Writetimeout .


7, Autoriteit 7%

Deze fout wordt momenteel verholpen: https://chromium- review.googlesource.com/c/chromium/src/+/2001234

Maar het heeft me geholpen om de nginx-instellingen te wijzigen:

  • gzip inschakelen;
  • add_header ‘Cache-Control’ ‘no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0’;
  • verloopt af;

In mijn geval fungeert Nginx als een reverse proxy voor de Node.js-toepassing.


Antwoord 8, autoriteit 5%

In ons geval was de reden een ongeldige koptekst.
Zoals vermeld in Edit 4:

  • neem de logboeken
  • kies in de viewer Evenementen
  • kies HTTP2_SESSION

Zoek iets soortgelijks:

HTTP2_SESSION_RECV_INVALID_HEADER

–> error = “Ongeldig teken in koptekstnaam.”

–> header_name = “charset=utf-8


Antwoord 9, autoriteit 5%

Ik heb meerdere keren met deze fout te maken gehad en dit was te wijten aan het overzetten van grote bronnen (groter dan 3 MB) van server naar client.


Antwoord 10, autoriteit 2%

We hebben dit probleem ondervonden op pagina’s met lange Base64-strings. Het probleem doet zich voor omdat we CloudFlare gebruiken.

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

Belangrijkste gedeelte uit de forumpost:

Na verder testen op incognitotabbladen in meerdere browsers, dan
het doen van de wijzigingen op de code van een BASE64 naar een echte .png-afbeelding, de
probleem is nooit meer voorgekomen, in ELKE browser. De .png had ongeveer 500kb
voordat het een base64 werd, heeft CloudFlare dus problemen met enorme regels van
tekst op dezelfde regel (aangezien base64 een lange tekenreeks is) als een proxy tussen
het domein en de heroku. Zoals eerder vermeld, direct raken
Heroku-url is ook nooit het probleem geweest.

De tijdelijke hack is om HTTP/2 op CloudFlare uit te schakelen.

Ik hoop dat iemand anders een betere oplossing kan maken waarvoor HTTP/2 op CloudFlare niet hoeft te worden uitgeschakeld.


Antwoord 11, autoriteit 2%

Standaard beperkt nginx de uploadgrootte tot 1 MB.

Met client_max_body_sizekun je je eigen limiet instellen, zoals in

location /uploads {
    ...
    client_max_body_size 100M;
} 

Je kunt deze instelling ook instellen op het http- of serverblok (Zie hier).

Dit heeft mijn probleem met net::ERR_HTTP2_PROTOCOL_ERROR opgelost


Antwoord 12, autoriteit 2%

Ik ben er niet van overtuigd dat dit het probleem was, maar via cPanel had ik gemerkt dat de PHP-versie op 5.6 stond en het veranderen naar 7.3 leek het probleem op te lossen. Dit was voor een WordPress-site. Ik merkte dat ik toegang had tot afbeeldingen en generieke PHP-bestanden, maar het laden van WordPress zelf veroorzaakte de fout.


Antwoord 13

Ik kreeg hetzelfde probleem (asp, c# – HttpPostedFileBase) bij het posten van een bestand dat groter was dan 1 MB (ook al heeft de applicatie geen beperking voor de bestandsgrootte), voor mij hielp de vereenvoudiging van de modelklasse. Als je dit probleem hebt, probeer dan enkele delen van het model te verwijderen en kijk of dit op een of andere manier helpt. Klinkt vreemd, maar werkte voor mij.


Antwoord 14

Ik heb dit probleem voor de laatste week nu ervaren, want ik heb geprobeerd om verwijderingsverzoeken naar mijn PHP-server via Ajax te verzenden. Ik heb onlangs mijn hostingplan geüpgraded, waar ik nu een SSL-certificaat op mijn host heb dat de PHP- en JS-bestanden opslaat. Sinds het toevoegen van een SSL-certificaat ervaar ik dit probleem niet langer. In de hoop dat dit helpt bij deze vreemde fout.


15

Ik heb ook geconfronteerd met deze fout en ik geloof dat er meerdere redenen erachter kunnen zijn. De mijne was, ARR werd time-out.

In mijn geval zakte Browser een verzoek aan een omgekeerde proxy-site waar ik mijn omleidingsregels heb ingesteld en die proxy-site uiteindelijk vraagt ​​om de daadwerkelijke site. Nu voor enorme gegevens duurt het meer dan 2 minuten 5 seconden en de aanvraagverzoekroutering time-out voor mijn server is ingesteld op 2 minuten. Ik heb dit opgelost door de ARR-time-out te verhogen met onderstaande stappen:
1. Ga naar IIS
2. Klik op de servernaam
3. Klik op de aanvraag Routering Cache in het middenvenster
4. Klik op Server Proxy-instellingen in rechtervenster
5. Verhoog de time-out
6. Klik op Toepassen


16

Mijn team zag dit op een enkel JavaScript-bestand dat we bedienden. Elk ander bestand werkte prima. We zijn overgestapt van http2terug naar http1.1en vervolgens net::ERR_INCOMPLETE_CHUNKED_ENCODINGof ERR_CONTENT_LENGTH_MISMATCH. We ontdekten uiteindelijk dat er een bedrijfsfilter (Trustwave) was die ten onrechte een “infoleeak” detecteerde (we vermoeden dat het iets in ons bestand / bestandsnaam heeft gedetecteerd dat op een sofinummer leek). Corporate krijgen om dit filter onze problemen op te lossen.


17

Voor mijn situatie werd deze fout veroorzaakt door het hebben van cirkelvormige referenties in JSON verzonden vanaf de server bij gebruik van een OMM voor ouder / kindrelaties. Dus de snelle en eenvoudige oplossing was

JsonConvert.SerializeObject(myObject, new JsonSerializerSettings { ReferenceLoopHandling = ReferenceLoopHandling.Ignore })

De betere oplossing is om DTO’s te maken die niet de referenties aan beide kanten bevatten (ouder/kind).


Antwoord 18

Ik had een ander geval dat een ERR_HTTP2_PROTOCOL_ERROR veroorzaakte die hier nog niet is genoemd. Ik had een kruisverwijzing gemaakt in IOC (Unity), waar ik klasse A had die refereerde aan klasse B (via een paar lagen), en klasse B die refereerde aan klasse A. Slecht ontwerp van mijn kant eigenlijk. Maar ik heb een nieuwe interface/klasse gemaakt voor de methode in klasse A die ik aanriep vanuit klasse B, en dat maakte het duidelijk.


Antwoord 19

In mijn geval was het WordPress dat nu PHP 7.4 vereist en ik draaide 7.2.
Zodra ik de update had uitgevoerd, verdwenen de fouten.


Antwoord 20

Ik heb dit probleem ondervonden bij het werken met Server Sent Events. Het probleem was opgelost toen ik merkte dat de domeinnaam die ik gebruikte om de verbinding te initiëren een slash bevatte, b.v. https://foo.bar.bam/mislukt met ERR_HTTP_PROTOCOL_ERRORterwijl https://foo.bar.bamwerkte.


Antwoord 21

In mijn geval (nginx op Windows die een app proxyt terwijl statische items op zichzelf worden weergegeven) toonde de pagina meerdere items, waaronder 14 grotere afbeeldingen; die fouten werden precies na 60 seconden getoond voor ongeveer 5 van die afbeeldingen; in mijn geval was het een standaard send_timeout van 60s waardoor die afbeeldingsverzoeken mislukken; het verhogen van de send_timeout maakte het werken

Ik weet niet zeker waardoor nginx op Windows die bestanden zo traag aanbiedt – het is slechts 11,5 MB aan bronnen die nginx bijna 2 minuten kost om te serveren, maar ik denk dat het onderwerp is voor een andere thread


Antwoord 22

Het lijkt erop dat veel problemen kunnen veroorzaken ERR_HTTP2_PROTOCOL_ERROR: In mijn geval was het een kleine syntaxisfout in een PHP-gegenereerde koptekst, Content-Type : text/plain. Mogelijk merkt u de ruimte vóór de dikke darm … dat was het. Werkt geen probleem wanneer de dikke darmecht naast de naam van de koptekst is zoals Content-Type: text/plain. Naakte slechts een miljoen uur om erachter te komen … De fout gebeurt alleen met Chrome, Firefox belaste het object zonder klacht.


23

Indien gewoon opnieuw opstarten bijv. Chrome Canarisch, met een vers profiel opgelost het probleem, dan een
is de “slachtoffer” van een mislukte chromen variatie ! Ja, er zijn manieren om af te kiezen voor een cavia in het veld Testen van Chrome.


24

In mijn geval
Header Params kan geen null of lege reeks instellen

{
 'Authorization': Authorization  //Authorization can't use null or ''
}

25

voor die landing van zoekmachines.

Ik had dit probleem onlangs, zij het niet PHP, eerder .NET en hoekig. Ik probeerde de overgrote meerderheid van de suggesties hier en op de MS-ondersteuningsforums voor IIS enz. Uiteindelijk moest ik IIS Express opnieuw installeren / repareren via het oude bedieningspaneel (dit herstelt het ontwikkelingscertificaat, ik gebruik niet eigenlijk IIS Express) en uitschakel HTTP / 2 onder de HTTPS-binding voor de toepassing. Natuurlijk is dit alleen voor een ontwikkelingsomgeving.

Other episodes