net::ERR_SPDY_PROTOCOL_ERROR 200 avec Google Chrome

c'est une erreur de TON Chrome (et c'est pas nouveau)
changer de navigateur: Firefox
ou chercher sur le net les corrections à faire

J'ai oublié de préciser que le problème survient aussi avec le navigateur safari sous un autre nom d'erreur et que cela est apparu brutalement...

Donc je ne vois pas pourquoi cela viendrait de moi. D'autant plus que j'ai demandé à pas mal de personnes qui retrouve le soucis sur Chrome et Safari du coup alors qu'avant aucun soucis.

tu as essayé avec Firefox?

Oui bien sur c'est le seul où cela fonctionne bien.

je confirme
meme combat sur safari et chrome : les images apparaissent et disparaissent illico

j'ai refait le test sur chrome et safari sans les bloqueurs adblock : meme résultat - pas d'image
par contre les pubs sont bien là

spdy est un protocole propriétaire à Chrome, repris et standardisé dans HTTP2

safari n'a rien à voir

je ne vois pas les pubs par contre, ni aucune image manquante d'ailleurs tout est propre
(je n'ai que firefox bien sûr)

Oui c'est lié au soucis pour safari puisque je répète encore une fois que je n'avais pas ces erreurs sur les deux navigateurs.

Safari :


Google Chrome :

1/ sur safari ce n'est pas une erreur spdy
2/ tu es à jour sur ton chrome?
https://www.itechgyan.com/err_spdy_protocol_error/

Toujours à jour oui...

Bref, je vois que malheureusement on doit subir ce genre de pb alors qu'avant migration rien...

Me demande si c'est pas un soucis de HTTP/2 lié également au SSL

http2 est un standard
http2 suppose HTTPS

firefox, et des chromes et des safaris lisent ta page
cela fait des années qu'il y a ces erreurs spdy (le brouillon du http2 google), que tu rencontres

en dehors de @kimnemesuive, deux personnes dans mon entourage, sur Mac, chrome & safari & firefox, pas de soucis non plus

tu as essayé de supprimer le profil de ton chrome et de réinstaller?

On me signale aussi que sur Microsoft EDGE également j'ai ce pb d'affichage d'images sur le forum bref, je suis perdu depuis cette migration...

Un corp OVH pourrait regarder ce qu'il se passe depuis cette migration sur Gravelines ?

on parle d'erreur ou d'affichage image?

Alors sur Chrome, le problème d'affichage des images est causé par l'erreur SPDY, mais j'ai également ce problème sur Safari, et EDGE avec une erreur différente mais tout autant lié, seul Firefox n'est pas impacté par mon problème.

Ce problème d'affichage des images concordent avec la migration sur Gravelines et le passage en HTTP/2 à mon sens.

pas de soucis sous FX oui
avant sur Paris, pas de http2
sur Gravelines si, mais ce n'est pas nouveau, et jamais vu/entendu parlé de ça, surtout comme souci systématique
kimnemesuive signalait effectivement que les images disparaissaient, mais comme c'était de la pub, je pensais à son adblock

et ton phpBB?
il y a un cache?
tu peux désactiver les redirections forcées sur https et tester en http?

C'est vraiment étrange cette erreur...
On en parlait par exemple en avril, mais au final on n'a pas vraiment su si c'est revenu suite à des modifs ou pas.
https://community.ovh.com/t/page-blanche-depuis-migration-datacenter
Sur le net personne n'a vraiment d'explication claire, et les solutions ne fonctionnent pas.

Et là idem, je l'ai chez moi sous Chrome et Brave. Sur 2 pc.
L'image apparaît, le loader de chargement reste une seconde, et hop l'image qui était en 200 repasse en failed.
Je suis chez Free.

> l'image qui était en 200 repasse en failed.

200 le serveur a délivré..., non?
après webkit ou blink fait ce qu'il veut avec ces images...

Mais carrément, l'image arrive bien, elle est en status 200.
Puis il y a un souci réseau/dns/chrome/webkit/ssl/... une seconde après et ça passe en failed.


qui devient


A noter :
-Les deux images php passent en failed;
-Les 3 vraies images restent en 200 (png, gif)

j'ai installé chromium, vu le souci

chargement, puis disparation
en final fails sur https://www.1mag.fr/forum/download/file.php?id=349&t=1mag.fr/forum/download/file.php?id=349&t=1

mais cette image se retrouve en lien

https://i.imgur.com/puFRpNz.png

et si tu regardais ce que fait ce script file.php?
quels headers envoie t il ?
cette image ne serait elle pas chargée deux fois
https://i.imgur.com/98Rsm00.png

on n'attends pas 5s pour la voir, mais celle qui apparaît au bout de 5s (requête sur file.php) échoue

il y a du ajax en cause?

si je démarre `chromium --use-spdy=off` avec speedy désactivé, même comportement
donc même spdy ne semble pas en cause

PS
enfin désactivé, ça reste à prouver, j'ai encore cette erreur ERR_SPDY_PROTOCOL_ERROR

ajax/spdy à revoir, je chercherais là
en attendant, tu peux pas virer l'utilisation de ce script?
phpBB est à jour?


des pistes à investiguer, je n'ai pas cherché plus

on n'a pas vraiment su si c'est revenu suite à des modifs ou pas.

si mise à jour spip & **important?** mise à jour hébergement, `.ovhconfig` (php-fpm):
```text
app.engine=php
app.engine.version=7.2
http.firewall=none
environment=production
container.image=stable
```

A tester :
Mettre à la fin de ton file.php
`header("Content-Encoding: none");`

Car là le serveur/proxy retourne une compression gzip, alors qu'on est sur des images, ça peut avoir un impact et rendre les header incorrects...

En tout cas, kyodev, je vois que ça t'intrigue autant que moi :D

> si mise à jour spip & important? mise à jour hébergement, .ovhconfig (php-fpm)

Oui, ce que je voulais dire c'est qu'on n'a pas trouvé la cause ou la solution pour relayer l'info.

je me penche sur les handicapés :o)

je parle des navigateurs /o\

bah, si, dans ce cas, SPIP était largement outdaté
mais passer en php -> php-ffm, c'est une autre génération

phpcgi n'a même pas du connaître spdy si ça se trouve
(perso je pense que c'est LA solution possible)
et comme on parle de migration, vieux cluster, je propose que @MICHAELP teste au plus tôt s'il s'est pas endormi :)

Bon les gars, tout d'abord merci de vous pencher sur ce soucis qui à l'air de vous passionner ^^

Pour répondre à @romainovh, concernant l'ajout du code dans file.php c'est un échec, il n'y a pas d'amélioration.

En revanche, je viens de modifier le .ovhconfig de php vers phpcgi et miracle il n'y a plus le problème !! seulement je ne veux pas utiliser phpcgi qui à l'air moins bien que php.

Cool !
Bien joué kyodev :-)

Je me demande si le changement n'a pas ajouté le header sur les "images php"
`content-type: image/png`
Car je m'étais focalisé sur le Content-encoding avec gzip...
Enfin j'en sais rien^^

a vrai dire je ne m'attendais pas à ça
phpcgi c'est mod_php (peut-être ça empêche spdy?)
mais c'est un mode ancien
de toute façon, en config actuelle (.ovhconfig indiqué), toute image correctement appelée dans une page html, sur Ovh à Gravelines, sera affichée en https, même avec Chrome
test a été fait?

donc au fond de moi, il faut se pencher sur phpBB, mais on a pas eu trop de retour à ce niveau
d'ailleurs de mémoire, j'ai vu de belles images de pub bien lourdes au milieu de la page?

donc se polariser sur Ovh, c'est comme se préoccuper de la route au lieu des amortisseurs sur une vielle voiture inconfortable

Avant d'ouvrir un post, j'avais bien évidemment fait des test en supprimant totalement les publicités du forum (je suis d'ailleurs sur la dernière version de phpBB) et le problème des images étaient toujours présentes, cependant ça m'embête vraiment de tourner sous phpcgi maintenant...

J'espère qu'il n'y aura pas un mauvais impact.

je debug mon script de détection sur cette page qui contient des traces de WP...

le logo:
```html
src="https://www.1mag.fr/wp-content/uploads/2015/12/logo-e1448669117317.pngmag.fr/wp-content/uploads/2015/12/logo-e1448669117317.png
```

il s'affiche ?

> le problème des images étaient toujours présentes

ce n'est pas un problème d'image
c'est un souci sur ton script file.php
tu te polarises sur le mauvais endroit

amha

c'est normal, le header est personnalisé, j'avais pas envie d'héberger deux fois le logo ^^ donc j'ai repris le lien de mon logo qui tourne sous WP pour la partie centrale, et j'ai également un bridge pour faire un menu. Cependant, j'avais désactivé ce bridge et le pb était toujours présent, donc ça n'a rien à voir.

Et oui il s'affiche

tu ne comprends pas ce que j'essaye de te dire:

les images s'affichent, voir ci dessus logo, ou favicon: wp-content/uploads/2015/12/favicon.png"

c'est ton **SCRIPT**

quelle version phpBB?
tu es allé voir sur phpbb?
mais libre à toi de persister sur Ovh

La dernière en date 3.2.7

Oui je suis allé voir et il n'y a rien de bien intéressant, le sujet sur SPDY a du être évoqué peu de fois.
Je n'ai pas encore ouvert de support chez eux car pour moi je pensais que ça venait de OVH étant donné qu'avant la migration je n'avais pas de soucis depuis des années.

oui, car à paris, c'était HTTP1, donc pas de speedy
spdy, comme HTPP2, c'est sur https

Ok bon bon pour l'instant je reste sur phpcgi, j'espère juste que j'aurai pas de mauvaises surprises.

non, de moins bonnes performances
certaines anciennes directives de configuration à conserver j'imagine
https://docs.ovh.com/fr/hosting/configurer-fichier-ovhconfig/

Je reste sur les header... Pour moi Chrome bloque car il y a une erreur dans les header, et il est un peu trop strict.
Dommage que je n'ai pas noté les header quand ça plantait.
En tout cas même là, on a des caractères étranges à la fin de :
`x-content-type-options: nosniff, nosniff”`

cache-control: public
content-disposition: inline; filename*=UTF-8''56.jpg
content-encoding: gzip
content-length: 13132
content-type: image/jpeg
date: Sat, 15 Jun 2019 08:57:15 GMT
expires: Sun, 14 Jun 2020 08:57:15 GMT
last-modified: Sat, 20 Apr 2019 20:04:35 GMT
server: Apache
status: 200
strict-transport-security: max-age=63072000; includeSubDomains
vary: Accept-Encoding
x-content-type-options: nosniff, nosniff”
x-frame-options: SAMEORIGIN, SAMEORIGIN
x-powered-by: PHP/7.2
x-xss-protection: 1; mode=block

D'où vient ce caractère pourri, ça pourrait être un cdn, un serveur, "proxy ovh" ?

Car le code source de phpbb ajoute un seul nosniff
`header('X-Content-Type-Options: nosniff');
https://github.com/phpbb/phpbb/blob/e7b7c66c774727560105888c4f5531320f645191/phpBB/includes/functions_download.php`

@kyodev avec le phpcgi on a désactivé quoi, on est toujours en http2 pourtant ?

_J'imagine un admin qui a raté son copier coller ou faute de frappe dans son script sh ^^ Ca serait un peu gros lol_

Ou une extension style sécurité sur phpbb ?

bien vu
pour moi, il a y une 2e requêtes, qui échoue après ***5 secondes***

```text
x-content-type-options: nosniff
...
x-content-type-options: nosniff”
```
avec *ce caractère bizarre*, une sorte de guillemet double:

` x-content-type-options: nosniffM-bM-^@M-^]$`

edit: avec le phpcgi, je suppute (j'ai pas regardé la doc :/)
on est sur un vieil apache, mod_php, spdy ne peut agir?

oui, peut-être aussi se pencher sur le template prosilver ou les modifications effectuées

Pour le nosniff j'en avais rajouté un dans le htaccess de la partie forum sans savoir si phpBB en avait ajouté un

il y a un caractère mal encodé comme l'a fait remarqué romain

Vous vérifiez les header avec quel outil car moi avec un outil sur le net je n'en vois qu'un ...

```text perso curl sous linux
```text
curl --head -XGET --user-agent firefox https://www.bbox-mag.fr/forum/viewtopic.php?p=12490#p12490
HTTP/2 200
date: Sat, 15 Jun 2019 10:49:54 GMT
content-type: text/html; charset=UTF-8
set-cookie: SERVERID105612=144051; path=/; max-age=900
server: Apache
x-powered-by: PHP/7.2
cache-control: private, no-cache="set-cookie"
expires: Sat, 15 Jun 2019 10:49:54 GMT
set-cookie: bbox-mag_forum_u=1; expires=Sun, 14-Jun-2020 10:49:54 GMT; path=/; domain=www.bbox-mag.fr; secure; HttpOnly
set-cookie: bbox-mag_forum_k=; expires=Sun, 14-Jun-2020 10:49:54 GMT; path=/; domain=www.bbox-mag.fr; secure; HttpOnly
set-cookie: bbox-mag_forum_sid=fde67237643d2949da2b8190bbdad456; expires=Sun, 14-Jun-2020 10:49:54 GMT; path=/; domain=www.bbox-mag.fr; secure; HttpOnly
x-frame-options: SAMEORIGIN, SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains
vary: Accept-Encoding
x-xss-protection: 1; mode=block
set-cookie: HttpOnly;Secure
x-content-type-options: nosniff”
``` ```

tu peux aussi faire un petit script php avec get_headers https://www.php.net/manual/fr/function.get-headers.php

ur le nosniff j'en avais rajouté un dans le htaccess de la partie forum sans savoir si phpBB en avait ajouté un

Suspense^^

Juste avec l'onglet network de chrome, tu peux voir les header :

Y a plus qu'un nosniff, mais... ça a pas l'air mieux... :/
cache-control: public
content-disposition: inline; filename*=UTF-8''56.jpg
content-encoding: gzip
content-length: 13521
content-type: image/jpeg
date: Sat, 15 Jun 2019 14:12:39 GMT
expires: Sun, 14 Jun 2020 14:12:39 GMT
last-modified: Sat, 20 Apr 2019 20:04:35 GMT
server: Apache
set-cookie: SERVERID105612=144051; path=/; max-age=900
set-cookie: HttpOnly;Secure
status: 200
strict-transport-security: max-age=63072000; includeSubDomains
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: PHP/7.2
x-xss-protection: 1; mode=block

Je suis perdu, le site semble lent à charger avec phpcgi... j'ai remis php ... ça me gonfle ce truc ^^

J'aimerai vraiment trouver l'origine du problème avec phpBB

```text
filename*=UTF-8''bbox.PNG
```
cette désignation n'est pas correcte, à priori

Bonjour à tous, depuis plusieurs semaine j'étais moi aussi ennuyé par ce "bug" "net::ERR_HTTP2_PROTOCOL_ERROR 200", il se produisait sur des images générées par PHP. Finalement, c'est au niveau des headers et notamment sur "header ('Content-Length: ' . filesize ($cache_file));" qui ne renvoyait visiblement pas la taille exact... j'ai supprimé cette header et tout fonctionne à merveille désormais. Visiblement donc Chrome vérifie l'exactitude des données transmises via les headers, si cela ne correspond pas = "failed"

Bien à vous

EDIT : 14/11/2019 à 15h15
J'ai trouvé la raison du mauvais calcul de content-lenght via filesize : la compression GZIP est active sur le fichiers PHP, il suffit donc d'exclure le fichier en question via un "SetEnvIfNoCase Request_URI ^/thumb\.php no-gzip dont-vary" dans le .htaccess. La aussi cela fonctionne et on conserve en plus le header Content-lenght.

C'est effectivement, la solution que j'ai effectué il y a quelques mois pour que ça remarche, je note sur le topic ton message en SOLUTION :)