Mon hébergeur (ICODIA) vient de me répondre que les problèmes que j'avais rencontrés (voir le fil) avaient été résolus en désactivant Gzip au niveau de leur serveur.
Effectivement, ça a l'air OK maintenant (à l'exception de SAFARI qui maintenant affiche le code source de la page 404, sans la boite de debug 1 erreur(s) dans le squelette : aucun squelette un_squelette_absent.html disponible)
je ne vois pas ton message sur la liste, pourtant, ta capture écran
apporte quelque chose d'intéressant.
Je pense que ces caractères sont le BOM de l'UTF8.
Si tu édites tes pages avec un éditeur de texte, il faut éventuellement
qu'il n'enregistre pas ces caractères.
Regarde l'encodage utilisé, il y a l'UTF8 et l'UTF8-y, l'un est avec le
BOM, et tu n'en as pas besoin. (et c'est déjà déclaré dans le charset).
Le présence de ces caractères avant le DOCTYPE posent alors problème.
D'ailleurs, est ce que tu as essayé de passer en HTML5, c'est
intéressant, et le DOCTYPE se simplifie. A vérifier bien sur pour le
reste du site.
Peut être qu'en virant ces caractères BOM de l'utf8 tout sera réglé.
En tout cas, c'est une étape.
Juste pour info, voulant en avoir le coeur net, je précise que j'ai tout viré pour refaire une install from scratch. Aucun plugin, aucun squelette perso. Neuf sortie d'usine en quelque sorte.
La copie d'écran est donc le résultat de ce que me renvoie le serveur en s'appuyant sur la dist.
Tout à l'heure, je n'ai pas répondu complètement à ta question :
les ?var_mode=recalcul se comportent normalement sauf si je glisse par exemple un INCLURE{fond=toto} dans article.html
là, le &var_mode=recalcul conduit au même symptome : la page n'est pas correctement interprétée par SAFARI
(voir copie d'écran ci-jointe)
Ce truc bizarre n'arrive que chez cet hébergeur, pas ailleurs (j'ai des sites chez OVH et chez free) ni en local
->>>> Donc si c'était cette histoire de BOM, qui gère ça mal ? SPIP ? Le serveur ? On a quoi comme levier d'action ?
Mon hébergeur est revenu sur son premier diagnostic : Gzip n'est effectivement pas en cause.
Pour info et si ça en intéresse qques uns, voici sa réponse
Bonjour,
Nous avons identifié le problème.
Le problème était que nous avons développés avec la fondation PHP des outils permettant d'augmenter la sécurité de l'exécution des scripts PHP sur notre plateforme.
Très peu d'hébergeurs supportent ce mode php, donc très peu de bugs sont détectés sur l'ensemble du développement de php par rapport à ce mode.
Il semblerait que la module core (base) de php lors d'une compression / décompression dynamique de code ne prenait pas tout le temps la taille réelle du buffer lors de la décompression, ajoutant 3 octets nuls. Ces 3 octets nuls étaient ensuite injectés lors de l'envoi du parser php au module de diffusion http d'Apache.