Bonjour,
voici mon problème : les urls inexistantes renvoient la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcg
J'utilise les urls propres 2 configurées via le couteau suisse (version : 1.8.07.01), sur un spip 2.0.8 [13982].
Avez-vous une idée pour corriger ce problème ?
Cordialement,
Sylvain
Bonjour,
j'ai eu ce soucis avec des url fantômes, si je me souvient bien c'est dans la table spip_url, mais aussi si tu utilise le couteau,
dans la catégorie des lames :
Administration
Format des URLs
faut activer la lame, ensuite,
-------
Action rapide, uniquement si vous savez ce que vous faites !
Réinitialiser les URLs stockées dans la base :
(Il y a actuellement 3 URL(s) en base)
----------
il faut cliquer sur "tout vider" ça pure la table spip_url des anciennes url's
Cordialement
Sylvain a écrit :
Bonjour,
voici mon problème : les urls inexistantes renvoient la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcgJ'utilise les urls propres 2 configurées via le couteau suisse (version : 1.8.07.01), sur un spip 2.0.8 [13982].
Avez-vous une idée pour corriger ce problème ?
Cordialement,
Sylvain_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.netInfos et archives : http://listes.rezo.net/mailman/listinfo/spip
Discuter chez rezo.netDocumentation de SPIP : http://www.spip.net/
Irc : de l'aide à toute heure : http://spip.net/irc
--
Signalez vos spams d'un simple clic. www.signal-spam.fr <https://www.signal-spam.fr/>
Bonjour et merci pour la réponse,
mais ça ne résout pas mon problème :
les urls inexistantes renvoient toujours la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcg
Quelqu'un a une idée ?
A moins que ce soit un bug ? Si vous pensez que c'est un bug, on peut poster ça quelque part ?
Il me semble que ça ne le faisait pas avec la version de spip 1.9.2
A +,
Sylvain
bobof a écrit :
Bonjour,
j'ai eu ce soucis avec des url fantômes, si je me souvient bien c'est dans la table spip_url, mais aussi si tu utilise le couteau,
dans la catégorie des lames :
Administration
Format des URLs
faut activer la lame, ensuite,
-------
Action rapide, uniquement si vous savez ce que vous faites !
Réinitialiser les URLs stockées dans la base :
(Il y a actuellement 3 URL(s) en base)
----------
il faut cliquer sur "tout vider" ça pure la table spip_url des anciennes url'sCordialement
Sylvain a écrit :
Bonjour,
voici mon problème : les urls inexistantes renvoient la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcgJ'utilise les urls propres 2 configurées via le couteau suisse (version : 1.8.07.01), sur un spip 2.0.8 [13982].
Avez-vous une idée pour corriger ce problème ?
Cordialement,
Sylvain_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.netInfos et archives : http://listes.rezo.net/mailman/listinfo/spip
Discuter chez rezo.netDocumentation de SPIP : http://www.spip.net/
Irc : de l'aide à toute heure : http://spip.net/irc
Bonsoir,
Le 24 juil. 09 à 21:28, Sylvain a écrit :
Bonjour et merci pour la réponse,
mais ça ne résout pas mon problème :
les urls inexistantes renvoient toujours la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcgQuelqu'un a une idée ?
A moins que ce soit un bug ? Si vous pensez que c'est un bug, on peut poster ça quelque part ?
Il me semble que ça ne le faisait pas avec la version de spip 1.9.2A +,
Sylvain
Ahh, merci Sylvain : je me sens moins seul :-))
Depuis SPIP 2.0 je ne sais plus gérer correctement les pages d'erreur 404. Depuis le début de l'année, j'ai un peu fait le tour des diverses pages traitant du sujet, sans jamais parvenir à quelque chose de totalement satisfaisant 
Un des noeuds du problème se situe dans le .htaccess fourni par SPIP qui cause un renvoi propre en cas d'erreur... et du coup avec l'en-tête 200, ce qui est dommage. Voire pénible quand tu veux valider ton site chez Gougle pour pouvoir utiliser les outils de webmestre puisque google n'accepte de valider par fichier html que s'il est capable de rencontrer une vraie erreur 404 avec un fichier inexistant.
A noter que les url propres n'y sont pour rien : je suis en train de finaliser un site sur lequel je ne les ai pas encore activées et c'est déjà tout pareil. La solution pour valider le site a été de temporairement virer le .htaccess, ce qui n'est pas une solution, mais un tourne autour.
Actuellement, le .htaccess fourni t'envoie sur la page d'accueil en cas de saisie d'une mauvaise url,
sauf à demander un fichier .php inexistant, ça marche comme ça chez toi aussi d'ailleurs :
http://www.creationsmosaiques.org/accueeeeil.php
Rigolo aussi : http://www.creationsmosaiques.org/?page=uzyetuyezurzety qui envoie sur une jolie carte de la méditerrannée avant une redirection vers la page d'accueil...
Bon avec un peu de chance, certains de la liste se sont penchés sur le problème ?
Hein, dites 
Michel
Bonsoir,
j'ai pas tout suivi concernant votre problématique, mais je peux vous proposer une piste, pas clé en main faut que je reprenne mes modestes notes,
dans la passé j'ai fais ceci :
faire une page html basique pour chaque erreur apache 400, 401, 402, 403, 404, etc...
dans le fichier htaccess de spip déclarer chacunes des erreur document :
*********
#################################
# gestion des erreurs 404
# voir La gestion des pages 404 - SPIP
# Pour que le serveur http renvoie les erreurs 404 vers SPIP, supprimer le '#'
ErrorDocument 404 /spip.php?page=404
ErrorDocument 403 /spip.php?page=403
ErrorDocument 402 /spip.php?page=402
##################
*********
etc .........
dès que j'ai mis la main sur la bonne doc apache je vous l'envoie.
Cordialement
Michel Roche a écrit :
Bonsoir,
Le 24 juil. 09 à 21:28, Sylvain a écrit :
Bonjour et merci pour la réponse,
mais ça ne résout pas mon problème :
les urls inexistantes renvoient toujours la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcgQuelqu'un a une idée ?
A moins que ce soit un bug ? Si vous pensez que c'est un bug, on peut poster ça quelque part ?
Il me semble que ça ne le faisait pas avec la version de spip 1.9.2A +,
SylvainAhh, merci Sylvain : je me sens moins seul :-))
Depuis SPIP 2.0 je ne sais plus gérer correctement les pages d'erreur 404. Depuis le début de l'année, j'ai un peu fait le tour des diverses pages traitant du sujet, sans jamais parvenir à quelque chose de totalement satisfaisant
Un des noeuds du problème se situe dans le .htaccess fourni par SPIP qui cause un renvoi propre en cas d'erreur... et du coup avec l'en-tête 200, ce qui est dommage. Voire pénible quand tu veux valider ton site chez Gougle pour pouvoir utiliser les outils de webmestre puisque google n'accepte de valider par fichier html que s'il est capable de rencontrer une vraie erreur 404 avec un fichier inexistant.
A noter que les url propres n'y sont pour rien : je suis en train de finaliser un site sur lequel je ne les ai pas encore activées et c'est déjà tout pareil. La solution pour valider le site a été de temporairement virer le .htaccess, ce qui n'est pas une solution, mais un tourne autour.
Actuellement, le .htaccess fourni t'envoie sur la page d'accueil en cas de saisie d'une mauvaise url,
sauf à demander un fichier .php inexistant, ça marche comme ça chez toi aussi d'ailleurs :
http://www.creationsmosaiques.org/accueeeeil.phpRigolo aussi : http://www.creationsmosaiques.org/?page=uzyetuyezurzety qui envoie sur une jolie carte de la méditerrannée avant une redirection vers la page d'accueil...
Bon avec un peu de chance, certains de la liste se sont penchés sur le problème ?
Hein, ditesMichel
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.netInfos et archives : http://listes.rezo.net/mailman/listinfo/spip
Discuter chez rezo.netDocumentation de SPIP : http://www.spip.net/
Irc : de l'aide à toute heure : http://spip.net/irc
--
Signalez vos spams d'un simple clic. www.signal-spam.fr <https://www.signal-spam.fr/>
Bonjour,
pour compléter ceci est intéressant :
http://www.apachefrance.com/Articles/7/page2.html#4xx
Cordialement
bobof a écrit :
Bonsoir,
j'ai pas tout suivi concernant votre problématique, mais je peux vous proposer une piste, pas clé en main faut que je reprenne mes modestes notes,
dans la passé j'ai fais ceci :
faire une page html basique pour chaque erreur apache 400, 401, 402, 403, 404, etc...
dans le fichier htaccess de spip déclarer chacunes des erreur document :
*********
#################################
# gestion des erreurs 404
# voir La gestion des pages 404 - SPIP
# Pour que le serveur http renvoie les erreurs 404 vers SPIP, supprimer le '#'ErrorDocument 404 /spip.php?page=404
ErrorDocument 403 /spip.php?page=403
ErrorDocument 402 /spip.php?page=402##################
*********
etc .........
dès que j'ai mis la main sur la bonne doc apache je vous l'envoie.
CordialementMichel Roche a écrit :
Bonsoir,
Le 24 juil. 09 à 21:28, Sylvain a écrit :
Bonjour et merci pour la réponse,
mais ça ne résout pas mon problème :
les urls inexistantes renvoient toujours la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcgQuelqu'un a une idée ?
A moins que ce soit un bug ? Si vous pensez que c'est un bug, on peut poster ça quelque part ?
Il me semble que ça ne le faisait pas avec la version de spip 1.9.2A +,
SylvainAhh, merci Sylvain : je me sens moins seul :-))
Depuis SPIP 2.0 je ne sais plus gérer correctement les pages d'erreur 404. Depuis le début de l'année, j'ai un peu fait le tour des diverses pages traitant du sujet, sans jamais parvenir à quelque chose de totalement satisfaisant
Un des noeuds du problème se situe dans le .htaccess fourni par SPIP qui cause un renvoi propre en cas d'erreur... et du coup avec l'en-tête 200, ce qui est dommage. Voire pénible quand tu veux valider ton site chez Gougle pour pouvoir utiliser les outils de webmestre puisque google n'accepte de valider par fichier html que s'il est capable de rencontrer une vraie erreur 404 avec un fichier inexistant.
A noter que les url propres n'y sont pour rien : je suis en train de finaliser un site sur lequel je ne les ai pas encore activées et c'est déjà tout pareil. La solution pour valider le site a été de temporairement virer le .htaccess, ce qui n'est pas une solution, mais un tourne autour.
Actuellement, le .htaccess fourni t'envoie sur la page d'accueil en cas de saisie d'une mauvaise url,
sauf à demander un fichier .php inexistant, ça marche comme ça chez toi aussi d'ailleurs :
http://www.creationsmosaiques.org/accueeeeil.phpRigolo aussi : http://www.creationsmosaiques.org/?page=uzyetuyezurzety qui envoie sur une jolie carte de la méditerrannée avant une redirection vers la page d'accueil...
Bon avec un peu de chance, certains de la liste se sont penchés sur le problème ?
Hein, ditesMichel
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.netInfos et archives : http://listes.rezo.net/mailman/listinfo/spip
Discuter chez rezo.netDocumentation de SPIP : http://www.spip.net/
Irc : de l'aide à toute heure : http://spip.net/irc
--
Signalez vos spams d'un simple clic. www.signal-spam.fr
<https://www.signal-spam.fr/>
Le 26 juil. 09 à 17:53, bobof a écrit :
Bonjour,
pour compléter ceci est intéressant :
http://www.apachefrance.com/Articles/7/page2.html#4xx
Cordialement
Bien,
je marque la page, et j'ai déjà fait un petit tour dedans et dans les suivantes, notamment sur celle où est décrite l'écriture d'un script gérant l'erreur apache. Et qu'y trouve-je ?
Tout d'abord, afin de protéger le script, nous testons l'existence de la variable REDIRECT_STATUS.
if (!isset($_SERVER["REDIRECT_STATUS"])) Header("Location: /");
Si elle existe, nous sommes redirigés vers le script suite à une erreur Apache : tout va bien, l'exécution du script continue. Dans le cas contraire, un internaute fait un appel direct au script : nous effectuons une redirection vers la racine du site via la fonction PHP header().
Evidemment ce n'est pas le script de SPIP dont on cause, mais l'idée de rediriger le visiteur sur la page d'accueil si on n'a pas intercepté l'erreur me rappelle quelque chose : justement le comportement de SPIP.
Reste à trouver le morceau de php qui s'exécute lorsqu'on demande une 404 suite à une erreur, et vérifier si le REDIRECT STATUS est bien pris en compte par SPIP. S'il y a un petit bogue à ce niveau là, ça pourrait très bien expliquer qu'alors il redirige le visiteur sur la page d'accueil.
-> Bon là-dessus si y'a un bon qui passe et qui peut m'aider à aller chercher au bon endroit tout de suite, qu'il ne se gêne surtout pas 
Tout de même ça m'étonne car ce comportement m'arrive sur des sites hébergés à divers endroits (1and1, OVH), en PHP5 (ou 4 d'ailleurs ça ne change pas le comportement), sur des sites pas si tordus que ça par rapport à la dist....
ON est que deux à connaitre ce problème ou bien ?
Michel
Bonjour,
ça me revois à une expérience avec le CS impossible d'activer une lame, heureusement que Pat est intervenu sinon le couteau je n'aurai jamais pu l'utiliser. C'est le filtrage des url par les hébergeurs, selon des séquences de caractères détecté dans les url's des redirections sont appliquées (chez mon hébergeur c'est la 403). Dans mon cas il s'agissait du mot toggle utilisé dans une commande du cs dans une url du style &toggle=xyz, Pat a remplacer ce mot par switch et le problème à disparu, j'en ai conclu (je peux me tromper) dans toggle y a ogg et ogg est un format vidéo si je ne me trompe pas, on pourrai vite faire un rapprochement entre vidéo et contenu illicite non ? à l'époque j'ai posé la question à mon hébergeur qui m'a confirmé le filtrage sur les url mais pas plus sur la liste des mots ou des séquences de caractères filtrées.
Alors quand je vois les url de cette forme ça m'interroge car pas très humain comme langage non ?
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcg
http://www.creationsmosaiques.org/accueeeeil.php
http://www.creationsmosaiques.org/?page=uzyetuyezurzety
Cordialement
Michel Roche a écrit :
Le 26 juil. 09 à 17:53, bobof a écrit :
Bonjour,
pour compléter ceci est intéressant :
http://www.apachefrance.com/Articles/7/page2.html#4xx
CordialementBien,
je marque la page, et j'ai déjà fait un petit tour dedans et dans les suivantes, notamment sur celle où est décrite l'écriture d'un script gérant l'erreur apache. Et qu'y trouve-je ?Tout d'abord, afin de protéger le script, nous testons l'existence de la variable REDIRECT_STATUS.
if (!isset($_SERVER["REDIRECT_STATUS"])) Header("Location: /");
Si elle existe, nous sommes redirigés vers le script suite à une erreur Apache : tout va bien, l'exécution du script continue. Dans le cas contraire, un internaute fait un appel direct au script : nous effectuons une redirection vers la racine du site via la fonction PHP header().
Evidemment ce n'est pas le script de SPIP dont on cause, mais l'idée de rediriger le visiteur sur la page d'accueil si on n'a pas intercepté l'erreur me rappelle quelque chose : justement le comportement de SPIP.
Reste à trouver le morceau de php qui s'exécute lorsqu'on demande une 404 suite à une erreur, et vérifier si le REDIRECT STATUS est bien pris en compte par SPIP. S'il y a un petit bogue à ce niveau là, ça pourrait très bien expliquer qu'alors il redirige le visiteur sur la page d'accueil.
-> Bon là-dessus si y'a un bon qui passe et qui peut m'aider à aller chercher au bon endroit tout de suite, qu'il ne se gêne surtout pasTout de même ça m'étonne car ce comportement m'arrive sur des sites hébergés à divers endroits (1and1, OVH), en PHP5 (ou 4 d'ailleurs ça ne change pas le comportement), sur des sites pas si tordus que ça par rapport à la dist....
ON est que deux à connaitre ce problème ou bien ?Michel
--
Signalez vos spams d'un simple clic. www.signal-spam.fr
<https://www.signal-spam.fr/>
Le 26 juil. 09 à 19:18, bobof a écrit :
Bonjour,
ça me revois à une expérience avec le CS impossible d'activer une lame, heureusement que Pat est intervenu sinon le couteau je n'aurai jamais pu l'utiliser. C'est le filtrage des url par les hébergeurs, selon des séquences de caractères détecté dans les url's des redirections sont appliquées (chez mon hébergeur c'est la 403). Dans mon cas il s'agissait du mot toggle utilisé dans une commande du cs dans une url du style &toggle=xyz, Pat a remplacer ce mot par switch et le problème à disparu, j'en ai conclu (je peux me tromper) dans toggle y a ogg et ogg est un format vidéo si je ne me trompe pas, on pourrai vite faire un rapprochement entre vidéo et contenu illicite non ? à l'époque j'ai posé la question à mon hébergeur qui m'a confirmé le filtrage sur les url mais pas plus sur la liste des mots ou des séquences de caractères filtrées.
Alors quand je vois les url de cette forme ça m'interroge car pas très humain comme langage non ?http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcg
http://www.creationsmosaiques.org/accueeeeil.php
http://www.creationsmosaiques.org/?page=uzyetuyezurzety
En examinant les en-têtes http renvoyées on trouve des choses intéressantes tout de même :
La seule url ci-dessus qui renvoie à la page 404 est la troisième, soit l'appel d'un fichier php inexistant
voici ce qu'on trouve dans le header ;
HTTP/1.x 404 Not Found"); ?><?php Header("cache-Control: no-store, no-cache, must-revalidate
==> ça sent le bug dans le code, non ?
Si on génère une vraie 404 par Apache tout seul, on reçoit plutôt ça : HTTP/1.x 404 Not Found
Y'a un vilain caractère qui traîne quelque part... va falloir trouver où !
Pour les autres, pas trace de HTTP/1.x 404 Not Found, on reçoit un code 200 (tout va bien) et on atterit sur la page d'accueil.
Je constate exactement le même comportement que chez toi. Avec sur certains sites en plus une erreur de squelette dans le cas où on cherche ?page=zzzzzz : il dit qu'il ne trouve pas le squelette zzzzz.html :-))
Enfin non, plutôt :-(((, car le message s'affiche même si on n'est pas connecté !
Exemple : http://vertaco.info/spip/?page=ddddd
Michel
Sylvain a écrit :
voici mon problème : les urls inexistantes renvoient la page d'accueil avec un code 200 (page trouvée), alors que ces pages n'existent pas.
Exemples :
http://www.creationsmosaiques.org/ghtrhgdrg.html
http://www.creationsmosaiques.org/ghtrdcg
Bonjour,
j'ai contourné le problème : ça me gênait surtout pour utiliser les webmaster tools de google qui demandent de valider le site de 2 façons :
- soit en mettant un fichier html avec un nom spécifique et ils vérifient que les pages inexistantes renvoient un code 404,
- soit en mettant une meta spécifique dans la page d'accueil.
J'ai utilisé la deuxième façon et c'est bon, je peux utiliser les outils.
Mais le problème de fond n'est pas résolu, j'ai essayé sur un spip en local et le problème ne se reproduit pas. Il semble donc que cela vienne de l'hébergeur : OVH avec php5.
Merci à ceux qui se sont penchés sur le problème. S'il y en a parmi vous qui ont le même hébergeur et le même problème, n'hésitez pas à me dire si vous trouvez une solution.
Bon week-end !
Sylvain