Un echo + flush ne fait pas le job malheureusement

Dev
#21

AH !

Je crois que j’ai une piste alors
Quand tu fais wget, tu es anonyme et du coup ça passe
dans le if () de la ligne 40 spip/spip: Dépôt officiel du core SPIP * Anciennement présent sur svn://trac.rezo.net/spip * Les plugins-dist faisant partie de la distribution SPIP sont présents dans https://git.spip.net/SPIP/[nom du plugin dist] - ecrire/action/menu_rubriques.php at master - spip - SPIP on GIT
qui finit par un exit;

Quand tu es identifié, ça va jusqu’à la fin de la fonction qui finit par un ajax_retour() ligne 70
et du coup après ça remonte dans public/aiguiller, et là surprise

on teste le ob_get_length() et si il est nul on envoie un 204

Donc a mon avis, pour vérifier et comprendre, si tu commentes la ligne 101 de public/aiguiller qui fait un
http_status(204);
ça devrait faire remarcher ton menu rubriques

Et si c’est bien le cas alors
1/ on peut fixer ton bug en ajoutant un exit dans la fonction menu_rubriques apres le ajax_retour() de la ligne 70
2/ on peut ajouter un commentaire sur sur http_status(204) en indiquant qu’il est possiblement buggy avec un zlib.output_compression

–
Cédric
Le 18 mai 2021 à 21:44 +0200, Arno* via Discuter de SPIP noreply@discuter.spip.net, a écrit :

Arno* arno
Mai 18
C’est pas mieux - mais c’est différent…
Là la réponse est immédiate: le menu se déplie, et rien du tout ne vient (mais pas de timeout).
Si j’essaie d’entrer l’URL de ?action=menu_rubriques directement dans le navigateur, ça ne semble charger aucune page.
Par contre, si je fais un wget sur cette même URL, ça me télécharge bien le fichier HTML complet du menu.
Le ob_implicit_flush ne change rien. Et au début de ce thread, j’avais essayé en désactivant tout sur mon site, et même résultat.
C’est un hébergement Infomaniak, php 7.4.16, pour Apache je ne trouve pas l’info dans php_info.
Voir le sujet ou répondre à ce courriel pour répondre.
Vous recevez ce courriel car vous avez activé la liste de diffusion.
Pour se désabonner de ces courriels, cliquez ici.

#22

Ohhhh (admiration…).

Yep, avec le http_status commenté, ça roule nickel. (Et tout ça sans que j’en comprenne le moindre mot :-))

#23

Ah donc mystère résolu, visiblement quand même lié à une config serveur bizarre ou en tout cas pas courante…
J’ai envoyé le patch final comme évoqué dans mon mail précédent

–
Cédric
Le 18 mai 2021 à 22:49 +0200, Arno* via Discuter de SPIP noreply@discuter.spip.net, a écrit :

Arno* arno
Mai 18
Ohhhh (admiration…).
Yep, avec le http_status commenté, ça roule nickel. (Et tout ça sans que j’en comprenne le moindre mot :-))
Voir le sujet ou répondre à ce courriel pour répondre.
Vous recevez ce courriel car vous avez activé la liste de diffusion.
Pour se désabonner de ces courriels, cliquez ici.

#24

Oui, c’est installé et ça roule!

Merci @cerdic, c’est impressionnant comme toujours.

1 « J'aime »
#25

Hello,

Je reprends ce fil, je pense que c’est le même type de problème qui surgit maintenant dans spip_loader chez le même hébergeur.

=> J’ai actuellement spip_loader.php (5.1.0) qui n’affiche plus rien. Visiblement c’est SL_fin_html() qui ne se termine pas. Si je balance un die() avant la boucle while (@ob_get_level()), ça fonctionne, et plus proprement si j’ajoute @ini_set("zlib.output_compression", "off"); en début de fichier, ça fonctionne.

Ça m’a donc l’air d’être la même cause de plantage.

#26

Hello @arno ,

On a sorti une version 6.1.0 du loader depuis. Est-ce que tu l’as utilisée et si oui, est-ce que ces erreurs ont disparus ? (c’est pour traiter #23 - Spip Loader ne termine pas les pages chez certains hébergeurs - spip_loader - SPIP on GIT que je demande :slight_smile: )