Status 302 non pertinent chez certains hébergeurs
Bonjour à tous !
Comme beaucoup de personnes, si j'en juge à ce qu'on peut trouver sur le net, j'ai eu des erreurs 302 "inexplicables".
Elles sont apparues quand j'ai voulu utiliser un formulaire de langue sur la page de sommaire : chaque fois qu'on changeait de langue, une page passablement laide indiquant "Erreur 302" était affichée un court instant, puis la page de sommaire était réaffichée.
Ce comportement se produisait chez l'hébergeur payant Oxito.Com, mais pas chez l'hébergeur gratuit Free ! J'ai donc déduit dans un premier temps qu'il pouvait s'agir d'un problème d'hébergeur, or il s'est avéré qu'avec l'option choisie chez Oxito, la redirection était en principe convenablement gérée.
Après avoir passé une bonne partie de la nuit dernière à chercher encore, j'ai fini par trouver dans le code source de Spip les lignes suivantes (fichier :ecrire/inc/headers.php/) :
if ($x = _request('transformer_xml'))
$url = parametre_url($url, 'transformer_xml', $x, '&');
// Il n'y a que sous Apache que setcookie puis redirection fonctionne
if (!$equiv OR ereg("^Apache", $GLOBALS['SERVER_SOFTWARE'])) {
`header("Location: " . $url);
} else {
`header("Refresh: 0; url=" . $url);
$equiv = "";
}
Si j'ai bien tout compris, Spip cherche à "deviner" si le serveur est un serveur Apache en cherchant le mot "Apache" dans la chaîne de $GLOBALS [ 'SERVER_SOFTWARE' ]. Seulement voilà, si pour cette chaîne, Free renvoie "Apache/ProXad [date]", Oxito renvoie "Oxito Web Hosting Service" alors qu'il s'agit clairement d'un serveur Apache, ou en tout cas compatible Apache, ne serait-ce que par la syntaxe des fichiers de configuration.
J'ai alors modifié le code source de la manière suivante :
if ($x = _request('transformer_xml'))
$url = parametre_url($url, 'transformer_xml', $x, '&');
// Il n'y a que sous Apache que setcookie puis redirection fonctionne
// if (!$equiv OR ereg("^Apache", $GLOBALS['SERVER_SOFTWARE'])) {
`header("Location: " . $url);
// } else {
// `header("Refresh: 0; url=" . $url);
// $equiv = "";
// }
Et là, plus de problèmes !!!
Ma conclusion en forme de double question est la suivante : tester la compatibilité Apache par la simple présence d'un mot-clef dans une chaîne de caractères est-elle pertinente, et n'y aurait-il pas moyen de rajouter une option dans la console admin avancée permettant de "forcer" Spip à considérer le serveur comme gérant correctement les redirections internes ?
