J’ai eu le même problème, vérifiez si vous avez suffisamment d’espace dans la partition / disque dur Nginx, nous en ajoutons et cela a fonctionné pour nous.

TL; DR : si vous mettez en cache des ressources, vérifiez l’espace disque de votre serveur nginx.

Notre scénario

Je ne suis pas sûr de savoir où poster ma réponse car cela pourrait être un cas particulier lors de l’obtention de ERR_SPDY_PROTOCOL_ERROR dans Chrome (et de l’erreur “Échec du chargement de la ressource” dans Firefox). Mais cet article m’a aidé à réduire le coupable. Ce ne sont pas les en-têtes, gzip, redirections ou adblock / ublock.

Nous avons déployé deux applications Web à partir de la machine et les deux fonctionnaient parfaitement bien. Récemment, nous avons déployé l’une des applications avec des modifications apscopes aux ressources mises en cache. Une fois le déploiement terminé, nous avons immédiatement reçu ERR_SPDY_PROTOCOL_ERROR de Chrome. Chose intéressante, il recevait un HTTP 200 et si vous naviguiez directement sur la ressource, Chrome rendrait la ressource. Cependant, le chargement de l’actif sur une page entraînerait son échec.

Assez curieusement, l’autre application Web était parfaitement correcte. En enquêtant sur le réseau interne de Chrome, nous avons découvert que le serveur fermait la connexion. Après plusieurs heures, nous avons déterminé que c’était parce que notre serveur nginx avait épuisé son espace disque. Je ne sais pas pourquoi cela entraînerait le chargement correct des ressources lorsque vous y accéderez directement, mais échouera lorsque vous chargez une page, mais la suppression de l’espace a immédiatement résolu le problème.

Il semble y avoir beaucoup de causes potentielles. Un que j’ai frappé aujourd’hui était la ligne d’en-tête

add_header X-Frame-Options: deny;

Le chrome actuel ne va pas sans cela avec ssl + http2 pour une raison quelconque. Les autres en-têtes X-Frame ne semblent pas poser de problème.

Il s’agit d’un problème connu qui existe entre les navigateurs Chromium et certains programmes antivirus tels que AVG et Avast, en particulier lors de l’utilisation d’une connexion SSL. Il ne peut pas être résolu à la fin de l’utilisateur. Il appartient aux développeurs de sites Web de prévenir ce problème.

La documentation pour les développeurs Web est ici: http://dev.chromium.org/spdy/spdy-best-practices

Voici quelques conseils utiles pour les développeurs qui ne sont pas spécifiquement mentionnés dans cet article:

• Soyez extrêmement prudent lorsque vous utilisez des en-têtes et des redirections, notamment 301 et 302
• Conservez toutes vos inclusions dans ou sous le même répertoire que votre access au nom de domaine, pas au-dessus du répertoire du serveur. Antivirus ne peut pas y accéder. Pour protéger vos fichiers inclus, créez un fichier .htaccess dans le répertoire includes et écrivez simplement une ligne: Refuser à tous
• Activer la compression Gzip. Si vous utilisez cPanel, cela peut être fait dans vos parameters d’optimisation de site Web.
• Gardez votre fichier .htaccess simple. La commutation des sorties du serveur pour créer différentes extensions de fichiers et redirect les clients utilisateurs créera des conflits inutiles.

D’après mon expérience, ce problème ne semble se produire que lors de l’utilisation de sessions pour stocker et transmettre des données. Les cookies, Get et Post semblent ne pas être affectés.

J’espère que cela t’aides.

J’avais un site qui le faisait, il s’est avéré que quelqu’un a oublié de mettre “Location:” dans une redirection PHP sur la première ligne de index.php, ce qui invalide l’en-tête. Apparemment, seul Chrome a pris soin de lui, le rest des navigateurs le chargeait toujours bien.

Comme avec l’OP, il s’agissait d’un problème intermittent pour moi et se produisant uniquement sur les requêtes AJAX> 2 Mo de taille.

Le problème a commencé après que nous sums passés d’un ELB classique d’AWS à ALB.

J’ai résolu ce problème en désinstallant Chrome, en supprimant mon profil utilisateur (sur Mac, supprimez le contenu de ~/Library/Application Support/Google/Chrome ), puis réinstallez-le.

J’ai vu cette erreur récemment après une mise à niveau du serveur.

Je le voyais pour tous les utilisateurs de Chrome, mais seulement par intermittence.

J’ai été en mesure de le résoudre pour tous les utilisateurs en les faisant utiliser la fonction de rafraîchissement de Chrome «Empty Cache et Hard Reload» pour le site. (F12 pour les outils Chrome, clic droit sur le bouton de rafraîchissement)

Je soupçonne que cela est lié à quelque chose mis en cache sur les certificates SSL utilisés.

Pour moi, c’était la configuration de Nginx qui ne permettait pas la méthode OPTIONS. Je n’avais que la liste blanche GET | PUT | POST | DELETE uniquement, alors quand Chrome a essayé d’envoyer la méthode OPTIONS, car Dieu sait pourquoi **, l’erreur a été reproduite.

Ouvrez Firefox et répétez la demande, puis consultez l’inspecteur réseau pour vérifier si des requêtes OPTIONS sont envoyées.

** probablement pour vérifier les options X-Frame ou la vérification HSTS.

Comme vous pouvez le constater d’après les autres réponses, beaucoup de choses peuvent en être la cause. Pour moi, j’avais un en-tête mal formé que les autres navigateurs ignoraient (un extra:). La seule réponse à cette question est une astuce de débogage, consultez les événements net-internals de Chrome lors du chargement de la page interrompue: chrome: // net-internals / # events

Pour moi, je savais que c’était une question de tête avec j’ai vu cette ligne

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