migration en spip 3.2.11 boucle JSON erreur 400

francoisM

Juin 2021

Bonjour,

j’ai deux spip :
– spip1 : sur serveur rhel 6 spip 3.0.11 php 5.3.3
– spip2 : centos 6 spip 3.0.17 php 5.3.13 ( ce serveur n’a jamais été mis à jour depuis 2012)
spip1 appelle spip2 via une boucle json dans la config actuelle ça fonctionne.
spip1 reçoit le fichier json de la part de spip2 et affiche les résultats.

Je dois refaire la machine spip2 sur rhel7 php5.4 spip 3.2.11, j’ai tout réinstallé, la connexion au spip2 fonctionne parfaitement, je peux faire des recherches dans son interface web.
Sur Spip1 J’ai modifié l’url dans la boucle json pour la faire pointer vers mon nouveau spip2
Quand je colle l’url utilisée par spip1 dans sa boucle json dans mon navigateur, spip2 renvoie bien un fichier json correctement formaté dont j’ai même validé le format et la syntaxe sur un site sur le net pour être sûr

Par contre l’interrogation depuis spip1 via la boucle data json vers ce nouveaux serveurs ne fonctionne pas.
Dans le log activé en modif ALL, j’ai une erreur 400, erreur datapath, alors qu’il est bien présent dans le fichier quand je le demande via mon navigateur ( du coup je ne suis pas sûr que spip2 renvoie vraiment le fichier alors que dans le log de spip2 on voit bien la requête arriver depuis spip1 et le json semble être généré sans erreur)
Dans l’interface web sur spip1 : Erreur json - Erreur de syntaxe ; JSON malformé

je n’ai plus d’idée , de piste à creuser,
J’ai l’impression que c’est le spip1 qui ne comprend plus ce qu’il reçoit.
Vu que j’ai changé de version de spip, je suis passé de 3.0.17 à 3.2.11 sur le serveur spip2, y’a t’il une config particulière sur le vhost par exemple des header à rajouter, je pense notamment aux CORS allow-origin etc ..

Tout cela fonctionnait bien avant, les codes des boucles n’ont pas changé hormis l’url d’appel vers le nouveau serveur.évidement

Merci d’avance pour toute l’aide que vous pourrez m’apporter.

François

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

michel_leble

Juin 2021

Bonjour,

> Quand je colle l’url utilisée par spip1 dans sa boucle json dans >mon navigateur, spip2 renvoie bien un fichier json correctement >formaté dont j’ai même validé le format et la syntaxe sur un site >sur le net pour être sûr

Peut-etre verifier l’encoding du JSON ?

francoisM

Juin 2021

Bonjour,

J’ai créé un mini squelette qui revoit simplement la variable #CHARSET sur tous les serveurs qui sont tous en spi 3 .
c’est utf-8 partout

J’ai même fait un test en recette en réinstallant spip1 et spip2 sur le même serveur et même dans ce cas ça ne fonctionne pas

Voilà le code du squelette qui créé le json sur le spip2

#HTTP_HEADER{Cache-Control: no-store, no-cache, must-revalidate}
#HTTP_HEADER{Pragma: no-cache}
#HTTP_HEADER{Content-type: application/json}
#HTTP_HEADER{Content-Type: application/json; charset=#CHARSET}
#CACHE{0}


<BOUCLE_a(ARTICLES){recherche} {par points} {inverse}{0,1}>[(#SET{pc,[(#EVAL{100/#POINTS})]})]</BOUCLE_a>
<B_articles>
{
    "recherche":{
        "total":"#GRAND_TOTAL",
        "total_page":"30",
                "article":[
<BOUCLE_articles(ARTICLES){recherche}{!par points}{!par date}{pagination 30}{","}>
                        {
                "titre":"[(#TITRE|textebrut|texte_backend)]",
                "url":"[(#URL_ARTICLE|url_absolue)]",
                "date":"[(#DATE|affdate|textebrut|texte_backend)]",
                "breadcrumb":"<BOUCLE_breadcrumb(HIERARCHIE){id_article}{" &gt; "}>[(#TITRE|couper{30})]</BOUCLE_breadcrumb>",
                "pertinence":"[(#SET{pt,[(#POINTS|mult{#GET{pc}})]})][(#GET{pt}|round)]",
                "descriptif":"[(#INTRODUCTION|textebrut|texte_backend)]"
            }
</BOUCLE_articles>
        ]
    }
}
</B_articles>
{
    "recherche":{
        "total":"0",
        "total_page":"0"
                }
}
<//B_articles>

si vous avez une idée , moi je ne sais plus quoi faire
Disons que ça devient des problèmes de code et là , je ne maitrise pas.

Merci pour votre aide

Indiquez l’intérêt que vous portez à cette réponse

0
michel_leble

Juin 2021
Bonjour,

J’aurais plutôt essayé de construire un array de données, puis de le convertir en json par un filtre Php.
Mais, s’il n’y a pas de caractères trop spéciaux dans les titres, etc. ça doit passer.

Avez-vous vérifié les données produites par le serveur dans le navigateur à l’appel de l’URL ?
Sont-elles lisibles ?

Le problème de syntaxe peut aussi venir d’une interruption du flux, si trop grand volume de données.

J’essaierais de limiter d’abord à deux ou 3 articles pour mes tests.

Si vous avez un problème CORS : vous devriez voir un message dans la console Javascript.

Vous pouvez essayer de donner la permission à tous :
#HTTP_HEADER{Access-Control-Allow-Origin: *}
Pour les tests, de façon à être sûr qu’un header est bien envoyé, j’ajouterais &var_mode=calcul à l’URL d’appel du serveur.
Indiquez l’intérêt que vous portez à cette réponse

0

francoisM

Août 2021

Bonjour
j’ai testé toutes les pistes que vous m’avez indiquées, mais ça ne marche pas .

Le problème est qu’il s’agit d’une boucle json exécutée par le serveur pas par mon navigateur. Le mode "log à fond" dans mes_options ne m’indique rien qui soit une piste à suivre

2021-08-02 16:37:15 10.44.201.60 (pid 5818) ecrire/inc/distant.php:L1477:lance_requete()::Pub:info : Recuperer / ?page=ws-recherche&recherche=retraite sur doge.rec.cir.spi:80 par Resource id #289
2021-08-02 16:37:15 10.44.201.60 (pid 5818) ecrire/inc/distant.php:L508:recuperer_url()::Pub:info : HTTP status 400 pour http://doge.rec.cir.spi/?page=ws-recherche&recherche=retraite

Mais pour avancer, j’ai fait un tcpdump sur le serveur spip2 et j’ai remarqué que la requête venant du serveur spip1 était en http /1.0 ,dans ce cas, le serveur spip2 répond Bad REquest.

09:30:07.199497 IP 172.20.13.109.60262 > vprophp10.spi.http: Flags [P.], seq 1:190, ack 1, win 229, options [nop,nop,TS val 530696460 ecr 128386028], length 189 : HTTP : GET / ?page=ws-recherche&recherche=retraite HTTP/1.0
.....
....
09:30:07.200299 IP vprophp10.spi.http > 172.20.13.109.60262 : Flags [P.], seq 1:393, ack 192, win 235, options [nop,nop,TS val 128386030 ecr 530696460], length 392 : HTTP : HTTP/1.1 400 Bad Request

Quand j’observe le trafic en appelant l’url appelé par spip1 depuis mon navigateur, la requête est faite en http/1.1 et le serveur spip2 répond correctement. j’ai la réponse correcte qui s’affiche dans mon navigateur.

11:01:13.864783 IP 10.44.201.60.60978 > vprophp10.spi.http: Flags [P.], seq 1:433, ack 1, win 2053, length 432 : HTTP : GET /spip.php ?page=ws-recherche&recherche=retraite HTTP/1.1
.....
.....
11:01:14.428498 IP vprophp10.spi.http > 10.44.201.60.60978 : Flags [P.], seq 1:5457, ack 433, win 237, length 5456 : HTTP : HTTP/1.1 200 OK

Savez vous comment je peux faire pour forcer le spip1 à faire sa requête en HTTP / 1.1 . ?

Je vous remercie par avance . si vous avez d’autres idées , n’hésitez pas
Indiquez l’intérêt que vous portez à cette réponse

0
michel_leble

Août 2021
Bonjour,
Ce serait donc peut-être un problème de niveau HTTP.
Beaucoup de serveurs utilisent encore http 1.0 , et ça devrait pouvoir marcher.
Un problème de compatibilité courante est le manque de HOST header dans le HTTP HEADER,
du côté des données envoyées par le serveur 1.0 (en http 1.1 il est exigé).
Le client http 1.1 alors refusera par un code 400 Bad request.
Comme c’est ce qui vous arrive justement, c’est peut-être le cas.

Vous devriez vérifier que le HTTP HEADER du côté serveur a bien
host : www.leclient.com
Indiquez l’intérêt que vous portez à cette réponse

0

francoisM

Août 2021

Disons que dans mon cas les deux spip sont sur le même serveur dans deux vhost différents.
Le spip1 fait l’appel json http://spip2/?page=ws-recherche&recherche=retraite dans une boucle DATA vers le spip2 et l’erreur se produit.
Pour tester j’ai remplacé, l’url appelée, par l’url vers l’ancien serveur que je dois migrer et là y’a pas d’erreur

le problème vient bien du spip2 qui visiblement n’accepte la requête qui pourtant est issue d’un vhost sur le même serveur apache avec la même conf que spip1.

Je ne vois pas quels headers sont manquants !
Soit sur spip1 je force l’appel Ajax en http1.1 soit sur spip2 je lui dis d’accepter l’appel , mais je ne vois pas comment faire ça !
Merci pour votre aide
Indiquez l’intérêt que vous portez à cette réponse

0

michel_leble

Août 2021

Bonjour,

Je ne pense pas que vous puissiez forcer le protocole depuis Ajax.
C’est décidé plutôt au niveau Apache ? Alors pourquoi spip1 fait une requête en http 1.0 c’est une vraie question et comment le changer ? Je n’ai pas de connaissances là-dessus.
Il y aura peut-être des gens plus qualifiés pour y répondre.

L’ancien serveur répond OK avec du http 1.0 ou du http 1.1 ?
Avez-vous une version différente d’Apache sur l’ancien serveur ? Ou la configuration Apache est-elle différente ?

Mais, si le serveur Spip2 travaille en 1.1 , il plantera la requête venant de Spip1 en http 1.0 si l’host n’est pas renseigné dans le header de la requête venant du Spip1.
Il y a plusieurs autres raisons possibles de code 400, peut-être que vous avez plus de détails dans les logs.

L’appel Ajax peut mettre à jour le host header, je viens de voir sur le net que c’est possible si tout se passe sur un même domaine.
Indiquez l’intérêt que vous portez à cette réponse

0

francoisM

Août 2021

Bonjour,

c’est à dire ? qu’est ce que je devrais regarder côté Plugins ?
Est ce que vous pouvez m’expliquer car je ne maîtrise pas du tout l’utilisation des plugins.

Merci d’avance
Indiquez l’intérêt que vous portez à cette réponse

0

Jack31

Août 2021

Désolé, la référence aux plugins était dans un message de spam d’un "expert" SEO qui n’avait rien à voir et qui a été supprimé. Je vous invite à reprendre sur les messages visibles de ce thread :)
Indiquez l’intérêt que vous portez à cette réponse

0
michel_leble

Août 2021
Bonjour,

En fait la requête en échec n’est pas faite en Ajax, mais elle utilise Spip. J’avais mal lu. Par défaut l’appel distant par Spip se fait en http 1.0.
Pour le changer en http 1.1, vous pouvez rajouter ceci dans le config/mes_options.php du serveur qui initialise la requête (Spip1) :
define('_INC_DISTANT_VERSION_HTTP', 'HTTP/1.1')
Indiquez l’intérêt que vous portez à cette réponse

0

francoisM

Août 2021

Bonjour,

je viens de tester
Quand j’ajoute votre paramètre dans mon fichier mes_options.php.
j’ai toujours le même problème

Spip1 est sur un nouveau serveur
– si je le fais appelé l’ancien spip2 qui est sur un vieux serveur , l’appel ajax fonctionne et mon résultat s’affiche dans spip1
– si je fais appelé par spip1 le nouveau spip2 qui se trouve sur le même serveur que spip1 , là ça marche pas.
Ancien spip2 centos 6 apache 2.2 php5.3 spip 3,1,17
Nouveau spip1 et spip2 rhel9 apache 2.4 php5.4.16 spip 3.2.11

Il n’y a quand même pas une si grande différence

Je ne sais pas !
Indiquez l’intérêt que vous portez à cette réponse

0
michel_leble

Août 2021
Attention, il faut une virgule à la fin de ligne en Php.
define('_INC_DISTANT_VERSION_HTTP', 'HTTP/1.1');
Sinon une page blanche provient souvent d’une erreur Php.
Vous pouvez activer l’affichage des erreurs PHP en ajoutant ces lignes dans le fichier config/mes_options.php :
error_reporting(E_ALL^E_NOTICE); ini_set ("display_errors", "On");
Ensuite il faut relancer et lire les logs
Indiquez l’intérêt que vous portez à cette réponse

0

michel_leble

Août 2021

Vous avez modifié votre message précédent qui mentionnait une page blanche et qui explique mon message ci-dessus. Je n’ai donc pas recu de notification, et n’ai vu votre réponse modifiée que par hasard.
— -
J’aurais aimé voir si un Tcpdump confirmait que la requête part en http 1.1 désormais, et si le message d’erreur avait ou non changé .

Comme vous utilisez une requête de serveur à serveur, il n’y a pas de problème de CORS.
Il se peut donc que ce soit la configuration de vos hosts qui empêche le dialogue.

Essayez avec curl.exe depuis Spip1 d’accéder à Spip2 (la page d’accueil par exemple).
Ça devrait marcher si la config hosts est ok.
Sinon vous pourrez avoir une indication selon l’erreur affichée.
Puis refaites-le avec l’url du json.