[spip-dev] problème de page blanche, proposition de patch

Dev
1

Rebonjour tout le monde...

J'ai attendu quelques moments, et j'ai fait quelques tests avec les versions
1.7.2prX, aucune d'entre elles ne solutionnent le problème de page blanche au
rechargement de la page.

Ce thread prouve que je ne suis pas encore bon pour porter une chemise blanche
avec des manches cousues... http://www.spip.net/threadspip2015-5854.html

Même la 1.7.2pr4 ne solutionne pas le problème.

Après avoir fouillé longuement dans le code de SPIP, je propose une solution.
Cette solution tient compte que si 10% des gens (j'exagère peut-être , mais
je sais que je ne suis pas le seul à avoir ce problème, plusieurs posts dans
les forums le montrent) ont des pages blanches à répétition, ils ne seront
pas tentés d'utiliser SPIP, ou en tout cas de laisser mozilla et consort.
Cette solution tient aussi compte du fait que les serveurs web sont
spécialisés pour tenir compte des requêtes HTTP et de déterminer eux mêmes le
type de réponse à déterminer à un si bas niveau , soit le 200 OK ou le 304
Not Modified.

Le problème provient vraiment des headers qui sont envoyés à Mozilla (le
problème se produit aussi avec FireFox, avec IE sous mac, etc) et d'une
combinaison avec apache (on dirait). Puisque le serveur web s'occupe déjà de
ne pas envoyer de données au client si ses données sont déjà dans le cache du
navigateur, pourquoi SPIP devrait-il s'en préoccuper ? (ça n'accélère pas,
puisque le serveur sait déjà que la page sera un 304).

C'est un problème difficilement acceptable pour une branche en production. Et
je vous rappelle que le bogue existe depuis le début de la 1.7

La solution (testée et fonctionnelle, n'allonge pas le temps de chargement,
génère un code 304, fait tout ce que c'est supposé faire) est de
désactiver/commenter/retirer les lignes 187 et 188 du fichier
inc-public-global.php3 (lignes en référence avec la version 1.97 du fichier
sur le CVS), soit ces lignes:

if ($lastmodified)
  $headers_only |= http_last_modified($lastmodified, $lastmodified + $delais);

Je veux bien tester d'autres suggestions, sauf que je dispose de peu de temps
pour coder autre chose. En confiant la tâche au serveur de s'occuper du
http_last_modified, on ne fait faire à SPIP que son travail (en plus que SPIP
a déjà un excellent système de CACHE). Si ces lignes sont retirées de la
dernière 1.7.x , au moins on sera certain que le problème ne traînera pas
jusqu'à la prochaine version et qu'on pourra régler définitivement la
situation si vous décidez de continuer à gérer quand même les last_modified.

Merci

2

Bonjour,

Je crois savoir me souvenir que certains étaient confrontés au même problème sous SPIP-AGORA. La solution trouvée et codée dans la version béta est la suivante :
Dans inc_version.php3, fonction http_last_modified

function http_last_modified($lastmodified, $expire = 0) {
  $gmoddate = gmdate("D, d M Y H:i:s", $lastmodified);
  if ($GLOBALS['HTTP_IF_MODIFIED_SINCE']) {
    $if_modified_since = ereg_replace(';.*$', '', $GLOBALS['HTTP_IF_MODIFIED_SINCE']);
    $if_modified_since = trim(str_replace('GMT', '', $if_modified_since));
    if ($if_modified_since == $gmoddate) {
      /***** Modification elebescond***************/
             //En attendant de mieux comprendre pourquoi ce code bloque l'affichage des pages
             //http_status(304);
      //$headers_only = true;
             /***** Fin modification elebescond@clever-age.com ***************/
    }
  }
  @Header ("Last-Modified: ".$gmoddate." GMT");
  if ($expire)
    @Header ("Expires: ".gmdate("D, d M Y H:i:s", $expire)." GMT");
  return $headers_only;
}

si ça aide :wink:

3

Sur Bloog, il y a une solution, peut etre un peu radicale, mais, je pense,
efficace ...

    @header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
    @header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");

    @header("Cache-Control: no-store, no-cache, must-revalidate");
    @header("Cache-Control: post-check=0, pre-check=0", false);
    @header("Pragma: no-cache");

@++

4

C'est un problème difficilement acceptable pour une branche en production. Et
je vous rappelle que le bogue existe depuis le début de la 1.7

La solution (testée et fonctionnelle, n'allonge pas le temps de chargement,
génère un code 304,

Comment peux-tu prétendre que ta solution génère un code 304 alors
qu'elle n'envoie même plus les en-têtes "Last-Modified" et "Expires" ?

Il vaudrait mieux trouver ce qui ne va pas du côté de Mozilla ou du
serveur Web, avec ces fameux 304. Quelle est la configuration du serveur
? (sous quelle forme - module, cgi... - est installé PHP, est-ce qu'il y
a un reverse proxy, etc.)

Du reste ce système est antérieur à la version 1.7.

Amicalement

Antoine.

5

> C'est un problème difficilement acceptable pour une branche en
> production. Et je vous rappelle que le bogue existe depuis le début de la
> 1.7
>
> La solution (testée et fonctionnelle, n'allonge pas le temps de
> chargement, génère un code 304,

Comment peux-tu prétendre que ta solution génère un code 304 alors
qu'elle n'envoie même plus les en-têtes "Last-Modified" et "Expires" ?

Ma "solution" (qui n'en est pas vraiment une), c'est de laisser le serveur web
faire son travail et de ne pas demander à SPIP de se prendre pour le serveur
web.

Quand on demande une page html à un serveur web, si on a déjà cette page dans
le cache de notre navigateur il ne nous la renvoie pas, code 304 côté
serveur, le navigateur prend la page dans son cache. Exactement comme ces
fonctions veulent le faire.

Il vaudrait mieux trouver ce qui ne va pas du côté de Mozilla ou du
serveur Web, avec ces fameux 304. Quelle est la configuration du serveur
? (sous quelle forme - module, cgi... - est installé PHP, est-ce qu'il y
a un reverse proxy, etc.)

J'ai essayé tout ça, j'ai envoyé plusieurs courriels à la liste, tenté de
chercher la réponse (qui se trouve manifestement quelque part dans la
fonction http_last_modified), sans succès.

Déjà 2 personnes depuis hier on mentionné que des gens (que je ne connais pas)
on proposé des solutions sur Spip-agora, sur Bloog, je vous ai parlé de ceux
du forum.

Manifestement, je ne suis pas seul. Je veux bien croire que ces problèmes sont
particuliers à certains navigateurs et à certains serveurs web; je répète, le
mien est une mandrake 9.2 installée tel quel, sans changements à la config de
base.

Ce n'est pas parce que ces problèmes n'affectent qu'une petite partie des
spipeurs qu'ils ne sont pas très problématiques.

Du reste ce système est antérieur à la version 1.7.

Ce qui montre donc qu'avant la version 1.7, ça fonctionnait. Les changements
induits brisent donc pour une partie des usagers le comportement.

J'étire beaucoup mes compétences en programmation... est-ce que quelqu'un
pourrait "revérifier" les fonctions http_last_modified et http_status ainsi
que le code dans inc-public-global.php3 ? Je suis volontaire pour tester
toute solution, je vous le répète. J'ai juste hâte que ça règle le problème.

Et je réitère que je ne vois pas du tout ce qu'enlever http_last_modified
cause comme problème puisque les serveurs web sont déjà conçus pour faire ça.

6

Salut,

Quand on demande une page html à un serveur web, si on a déjà cette page dans
le cache de notre navigateur il ne nous la renvoie pas, code 304 côté
serveur, le navigateur prend la page dans son cache.

Oui, quand on demande une page HTML... Quand on demande un script PHP,
le serveur Web laisse la main à PHP et ne s'occupe pas de rajouter des
en-têtes. Essaie avec curl si tu n'es pas convaincu.

J'ai essayé tout ça, j'ai envoyé plusieurs courriels à la liste, tenté de
chercher la réponse (qui se trouve manifestement quelque part dans la
fonction http_last_modified), sans succès.
je répète, le
mien est une mandrake 9.2 installée tel quel, sans changements à la config de
base.

Oui, je me souviens qu'on en a déjà parlé longuement... Seulement, sans
accès au serveur et sans arriver à reproduire le problème (je n'ai
jamais eu de pages blanches sous Mandrake), il est impossible pour nous
de diagnostiquer correctement.

Si quelqu'un peut nous donner un accès à un serveur "malade", qu'il
n'hésite pas :wink:

Amicalement

Antoine.

7

Je vais peut-être dire une bêtise mais que se passe-t-il avec les URL
récrits (article123.html) ?

8

La même chose : le serveur réécrit l'URL, puis passe l'URL interne
(article.php3?...) à PHP sans toucher aux en-têtes.

Amicalement

Antoine.