Ik en een paar van mijn collega’s kregen de net::ERR_SPDY_PROTOCOL_ERROR-fout.

We gebruiken ngnix versie 1.8.0. De fout is niet stabiel (moeilijk te repliceren) en het Ngnix-foutlogboek bevat deze fout niet.

Hoe zou u ons adviseren dit op te sporen en op te lossen?

Antwoord 1, autoriteit 100%

Ik kwam deze vraag tegen toen ik hulp zocht voor het probleem dat ik ondervond met ERR_SPDY_PROTOCOL_ERROR in Chrome. Ik dacht dat dit anderen ten goede zou kunnen komen.

Onze situatie / oplossing: we gebruiken een AWS Application Load Balancer die is verbonden met EC2-instanties. Een van de scripts die we uitvoeren op EC2-proxyverzoeken van de clientbrowser. We hebben onlangs het script bijgewerkt – geen relevante wijzigingen – en hebben gemerkt dat zowel Chrome- als Safari-verzoeken aan het proxyscript begonnen te mislukken. Chrome toonde de ERR_SPDY_PROTOCOL_ERROR-fout en toen we erin groeven, konden we zien dat dit verzoek HTTP/2 gebruikte. Firefox-verzoeken bleven goed werken.

Onze oplossing: we hebben HTTP/2-ondersteuning in de ALB uitgeschakeld. Het probleem is meteen opgelost.

AWS CLI-opdracht:

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false

Antwoord 2, autoriteit 80%

Ik had hetzelfde probleem, controleer of je genoeg ruimte hebt op de Nginx-partitie/HDD, we voegen wat toe en het werkte voor ons.

Antwoord 3, autoriteit 65%

TL;DR: als u activa in de cache plaatst, controleer dan de schijfruimte op uw nginx-server.

Ons scenario

Ik weet niet zeker waar ik mijn antwoord hierop moet plaatsen, omdat het een randgeval kan zijn bij het ophalen van de ERR_SPDY_PROTOCOL_ERROR in Chrome (en de equivalente fout ‘bron niet laden’ in Firefox). Maar dit bericht heeft me geholpen de boosdoener te achterhalen. Het waren geen headers, gzip, omleidingen of adblock/ublock.

We hebben 2 webapplicaties geïmplementeerd vanaf de machine, en beide werkten prima. Onlangs hebben we een van de applicaties geïmplementeerd met wijzigingen in de middelen in de cache. Nadat de implementatie was voltooid, kregen we onmiddellijk de ERR_SPDY_PROTOCOL_ERROR van Chrome. Interessant genoeg ontving het een HTTP 200 en als u rechtstreeks naar het item navigeerde, zou Chrome het item weergeven. Als het item echter op een pagina wordt geladen, zou het mislukken.

Interssant genoeg was de andere webtoepassing prima in orde. Bij het onderzoeken van de interne onderdelen van Chrome ontdekten we dat de server de verbinding verbrak. Na enkele uren kwamen we tot de conclusie dat onze nginx-server geen schijfruimte meer had. Ik weet niet waarom dat ertoe zou leiden dat de items correct worden geladen wanneer u er rechtstreeks naar navigeert, maar mislukken wanneer u een pagina laadt, maar het vrijmaken van ruimte loste het probleem onmiddellijk op.

Antwoord 4, autoriteit 25%

Zoals je aan de andere antwoorden kunt zien, kunnen veel verschillende dingen dit veroorzaken. Voor mij had ik een misvormde header die andere browsers gewoon negeerden (een extra :). Het enige antwoord hiervoor is een foutopsporingstip, check de net-internals-gebeurtenissen van Chrome terwijl u de kapotte pagina laadt: chrome://net-internals/#events

Voor mij wist ik dat het een header-probleem was toen ik deze regel zag

t=65422 [st=53]      HTTP_TRANSACTION_READ_HEADERS  [dt=4]
                 --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) 

Na het verwijderen van de extra : uit de headerreactie, begon HTTP/2 te werken in Chrome. Ik raad aan om een ​​onbewerkte reactie van uw server te krijgen en zeer nauwkeurig te controleren om er zeker van te zijn dat er geen syntaxisfouten zijn.

Antwoord 5, autoriteit 20%

Er lijken veel mogelijke oorzaken te zijn. Een die ik vandaag raakte, was de kopregel

add_header X-Frame-Options: weigeren;

Huidige chrome zal dat om de een of andere reden blokkeren met ssl+http2. Andere X-Frame-headers lijken geen probleem te zijn.

Antwoord 6, autoriteit 15%

Dit is een bekend probleem dat bestaat tussen Chromium-browsers en bepaalde antivirusprogramma’s zoals AVG en Avast, vooral bij gebruik van een SSL-verbinding. Het kan niet worden opgelost aan de kant van de gebruiker. Het is aan website-ontwikkelaars om te voorkomen dat dit probleem optreedt.

De documentatie voor webontwikkelaars is hier: http://dev.chromium.org /spdy/spdy-best-practices

Hier zijn enkele nuttige tips voor ontwikkelaars die niet specifiek in dat artikel worden genoemd:

• Wees uiterst voorzichtig bij het gebruik van headers en omleidingen, vooral die van 301 en 302
• Bewaar al uw include in of onder dezelfde directory als uw domeinnaamtoegang, niet boven de directory op de server. Antivirus kan ze daar niet openen. Om uw include-bestanden te beschermen, maakt u een .htaccess-bestand in de include-directory en schrijft u eenvoudig één regel: Deny from all
• Gzip-compressie inschakelen. Als u cPanel gebruikt, kunt u dit doen in uw instellingen voor Website-optimalisatie.
• Houd je .htaccess-bestand eenvoudig. Het wisselen van serveruitgangen om verschillende bestandsextensies te maken en het omleiden van gebruikersclients zal onnodige conflicten veroorzaken.

Naar mijn ervaring lijkt dit probleem zich alleen voor te doen wanneer Sessies worden gebruikt om gegevens op te slaan en door te geven. Cookies, Get en Post lijken niet te worden beïnvloed.

Hopelijk helpt dit.

Antwoord 7, autoriteit 15%

Voor mij was het de Nginx-configuratie die de OPTIONS-methode niet toestond. Ik had alleen GET|PUT|POST|DELETE op de witte lijst gezet, dus toen Chrome probeerde de OPTIONS-methode te verzenden, want God weet waarom**, werd de fout gereproduceerd.

Open Firefox en herhaal het verzoek. Kijk vervolgens naar de netwerkcontroleur om te controleren of er OPTIONS-verzoeken worden verzonden.

** waarschijnlijk om te controleren op X-Frame-Options of HSTS-verificatie.

Antwoord 8, autoriteit 5%

Ik had een site die dat deed, het bleek dat iemand was vergeten “Locatie: ” in een PHP-omleiding op de eerste regel van index.php te zetten, waardoor de header ongeldig werd. Blijkbaar kon alleen Chrome er iets om geven, de rest van de browsers laadde het nog steeds prima.

Antwoord 9, autoriteit 5%

Net als bij de OP was dit een incidenteel probleem voor mij en gebeurde het alleen bij AJAX-verzoeken > 2 MB groot.

Het probleem begon nadat we waren overgestapt van een klassieke AWS ELB naar ALB.

Ik heb dit opgelost door Chrome te verwijderen, mijn gebruikersprofiel te verwijderen (verwijder op mac de inhoud van ~/Library/Application Support/Google/Chrome) en vervolgens opnieuw te installeren.

Antwoord 10, autoriteit 5%

Ik heb deze fout onlangs gezien na een serverupgrade.

Ik zag het voor alle gebruikers in Chrome, maar slechts af en toe.

Ik heb het voor alle gebruikers kunnen oplossen door ze de Chrome-verversingsfunctie ‘Leeg cachegeheugen en harde herlaadbeurt’ voor de site te laten gebruiken.
(F12 voor Chrome-tools, klik met de rechtermuisknop op de vernieuwingsknop)

Ik vermoed dat het te maken heeft met iets dat in de cache is opgeslagen over de gebruikte SSL-certificaten.

Antwoord 11, autoriteit 5%

Controleer de locatie van uw proxycachepad – controleer of het bestaat, ruimte heeft en of de rechten en eigenaar het nginx-proces toestaan ​​om naar het pad te schrijven.

bijv. nginx.conf (fragment)

proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;

… controleer vervolgens of het pad /proxy_cache eigendom is van en beschrijfbaar is door nginx.

Antwoord 12, autoriteit 5%

In mijn geval heb ik dit opgelost door de chunk groter te maken :

http2_chunk_size             300k;

Antwoord 13, autoriteit 5%

Als je krijgt

ERR_HTTP2_PROTOCOL_ERROR

OF

ERR_SPDY_PROTOCOL_ERROR

in de Chrome- of Safari-browser met behulp van Nginx Content-Security-Policy, inspecteer dit probleem eerst door de verborgen Chrome-interface te openen: chrome://net-internals/#events en “live HTTP” te selecteren /2 sessies" knop onder het tabblad HTTP/2.

Als u iets als hieronder krijgt als resultaat tegen uw domein na een vernieuwing:

HTTP2_SESSION_RECV_INVALID_HEADER

–> error = "Ongeldig teken in headernaam."

U moet de CSP-header op de volgende manier schrijven:

add_header Content-Security-Policy "<values>";

Deze methode werkte prima voor mij.

OPMERKING: Spaties zijn niet toegestaan ​​in CSP. Gebruik witruimte om alleen onderscheid te maken tussen de beleidsparameter en de waarde ervan. Als u dit probleem in Chrome wilt reproduceren, kunt u add_header Content-Security-Policy: "<values>"; gebruiken met aanvullende : die als ongeldig wordt beschouwd.

Antwoord 14

Onze huidige structuur was

AWS ELB=>Nginx=>JBoss

Het gaf ons dezelfde crome-fout ERR_SPDY_PROTOCOL_ERROR

Het werkte goed zonder http2, dat standaard is ingeschakeld door ELB, we wilden niet dat het werd uitgeschakeld.
Bij verder onderzoek werd opgemerkt dat onze JBoss-server het antwoord comprimeerde. We hebben het uitgeschakeld en alles werkte prima.