Redirect permanent /index.html http://www.monsite.fr/ : Ko ?

[hibou57]

Bonsoir,

Pourquoi est-ce que ce genre de redirection ne marche pas ?
Redirect permanent /index.html http://www.example.com/
Alors que si je fais
Redirect permanent /machin.html http://www.example.com/
ca fonctionne....

Des idées ?

J'ai aussi testé un CGI qui fait une redirection (code 301) vers http://www.example.com/ si on lui demande /index.html, mais là idem, ça n'est pas plus concluent, et c'est dans l'eau même quand on demande / (!)

C'est à n'y rien comprendre.

Comment tout cela est-il possible ?

Quand Apache renvoie index.html alors qu'on lui demande /, il ne le fait pourtant pas par une redirection... alors il ne devrait pas y avoir de boucle de redirection.

Vous avez des idées ?

[rock-mantique]

car index.html est deja ouvert dans le domaine , ce qui provoque une boucle infernale qui si elle n'est pas areté peut mettre down un serveur

l'ideal serai de faire dans une page php le code suivant dans la toute premieres ligne

Code: Tout sélectionner

<?
if($_SERVER['REQUEST_URI'] == "/index.php")
{
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://".$_SERVER['HTTP_HOST']."/");
exit;
die("Redirection");
}
?>


[KOogar]

il est bien ce post, il permet de mettre fin au fait que l'on ne pas rediriger l'index.php via .htaccess

Apres moultes tests de verif voici les 2 codes qui permettent de rediriger l'index sur la racine sans erreur 500

le premier est le plus simple car il s'agit de index.html

Code: Tout sélectionner

RewriteCond %{REQUEST_URI} ^/index.html
RewriteRule $ http://www.site.ext/ [R=301,L]

c'est le second avec index.php qui est plus astucieux, l'astuce est tout simplement de verifier si c'est un fichier physique ou non et le tour est jouer

Code: Tout sélectionner

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^/index.php$
RewriteRule $ http://www.site.ext/ [R=301,L] 

Keep going !!

[hibou57]

Hola los amigos,

Merci pour vos deux réponses qui valent autant que des dizaines de réponses. Mais en même temps vos deux réponses sont tellement interessantes qu'elles m'eveillent plein d'autres questions.

car index.html est deja ouvert dans le domaine

Que veux-tu dire par "ouvert dans le domaine" ? Cette expression est obscrure à ma compréhension.

, ce qui provoque une boucle infernale qui si elle n'est pas areté peut mettre down un serveur

J'ai bien cru remarquer un boucle. Mais par contre je pensais que les serveurs étaient protégés, ou que les navigateurs destectaient ces boucles. En tous cas j'avais constaté que la requête n'aboutissait pas, et que Opera, qui detecte pourtant les cycle de redirection, n'a détecté aucun cycle.

Ce que tu dis m'inquiète tout de même, parce que je suis sur un serveur mutualisé.

Code: Tout sélectionner

<?
if($_SERVER['REQUEST_URI'] == "/index.php")
{
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://".$_SERVER['HTTP_HOST']."/");
exit;
die("Redirection");
}
?>


C'est presque (voir ci-aprés) ce que j'avais fait, si ce n'est que chez moi ce n'est pas du PHP, mais du CGI binaire.

Je note tout de même une différence, et c'est là que je me dis que j'ai été bête : au lieu de tester REQUEST_URI, je testais PATH_INFO.

Il faudrait que je vérifie, mais peut-être alors que PATH_INFO ne peut jamais être à "/", contrairement à REQUEST_URI qui pourrait finir avec "/" ?

Pourtant il m'avais bien semblé remarquer que PATH_INFO est toujours égale à ce qui suit le nom de domaine dans REQUEST_URI.

Est-ce que je me trompe ?

Je suis pourtant quasiement certains d'avoir validé cette question quand j'avais mis en place ces CGI.

il est bien ce post, il permet de mettre fin au fait que l'on ne pas rediriger l'index.php via .htaccess

Alors on va bien soigné ce fil, bien le documenté, et en faire un beau post-it

Code: Tout sélectionner

RewriteCond %{REQUEST_URI} ^/index.html
RewriteRule $ http://www.site.ext/ [R=301,L]

J'avais testé un code trouvé sur le web, basé sur RewriteRule. Mais j'ai eu la mauvaise surprise de découvrir que le serveur renvoyait un message d'erreur au navigateur, et que ce message d'erreur contenait un chemin qui est censé être totalement invisible à l'internaute (un chemin qui fait partie de la chaîne de traitement par les CGI). Alors je n'avais pas beaucoup aimé ça

Mais par la même occasion : quelles sont les différences fondamentales entre RewriteCond+RewriteRule et Redirect/RedirectMatch ?

RewriteRule génère bien également une redirection ou pas ? Jai un doute, à cause du comportement que j'ai constaté (l'indiscrétion du message d'erreur précédement désigé).

c'est le second avec index.php qui est plus astucieux, l'astuce est tout simplement de verifier si c'est un fichier physique ou non et le tour est jouer

Code: Tout sélectionner

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^/index.php$
RewriteRule $ http://www.site.ext/ [R=301,L] 

Keep going !!

Mais peut-on l'utiliser avec un index.html également ?

Serait-il possible de décoder ces lignes ? Je vais essayer de le faire.... et de repasser.

En attendant, puisque je parle de documenter, je vais peut-être au moins documenter ma propre ligne, celle que j'avais introduite, à l'intention de ceux/celles qui ne connaîtrait pas.

Code: Tout sélectionner

Redirect permanent /page.html http://www.monsite.fr/

Redirect: c'est simplement la commande de redirection
parmanent: c'est le status de la redirection. Une redirection peut être permanente, temporaire, ou non-cachable (d'autres mots clés remplacent alors l'argument "permanent").
/page.html: c'est le nom de chemin relatif au nom de domaine. C'est ce chemin que l'on redirige. Il est toujours local, et c'est logique, parce qu'on ne peut pas faire une redirection concernant abc.com depuis xyz.fr.
-http://www.monsite.fr/: c'est la destination vers laquelle on est redirigé(e) si on veut accéder à /page.html. Cette URL est globale. On pourrait penser qu'elle pourrait être local, puisqu'on peut vouloir rediriger vers une autre page du site. Mais on doit aussi pouvoir rediriger vers un autre site. Et au lieu d'avoir deux syntaxes possibles, l'équipe de conception de Apache, a préféré ne prendre qu'une seule syntaxe : celle qui permet d'exprimer les deux cas. Donc même si vous redirigez vers le même nom de domaine, vous devez quand-même indiquer ici le nom de domaine.

Vous l'aurez compris ami(e)s lecteur(rice)s : ceci ne fonctionne malheureusement pas avec le cas particulier des page d'index devant être renvoyer vers la racine du site lui-même.

Bon, je vais voir pour le décodage des RewriteCond et RewriteRule, que je n'ai jamais utilisé.

A plus tard ... Bye-bye

[hibou57]

Je viens de comprendre : l'URL rewriting est une re-écriture dont l'effet s'exprime en interne (je pensais que c'était une re-écriture qui s'exprimait par une redirection). Ce mécanisme a une grande proximité avec le traitement CGI, qui lui aussi est interne.

Tout est clairement expliqué dans cette article de WRI:
http://www.webrankinfo.com/analyses/aut ... riting.php
(voir en milieux de page)

Mais apparement on peut également l'utiliser également pour faire des redirections.

+ RewriteRule est un mot-clé spécifique au module mod_rewrite qui indique que la ligne définit une règle de réécriture.
+ Ensuite vient l'URL à réécrire, c'est-à-dire l'URL « propre » sans existence physique sur le serveur.
+ Enfin vient l'URL réécrite, c'est-à-dire l'URL telle qu'elle sera appelée en interne sur le serveur.
+ Ces 3 éléments doivent être écrits sur une seule ligne, et séparés par un ou plusieurs espaces à chaque fois

EDIT: Je viens de parvenir à mes fins, avec le CGI. Il fallait effectivement utiliser REQUEST_URI au lieu de PATH_INFO. Les deux sont quasiement identiques, mais à une différence prêt : PATH_INFO est modifié par Apache. Ainsi, quand Apache reçoit une requête -monsite.fr/, il transmet "/index.html" dans PATH_INFO et "/" dans REQUEST_URI. REQUEST_URI peut faire la différence entre "/" et "/index.html", tandis que PATH_INFO ne fait pas la différence entre les deux.

Comme mon CGI testait PATH_INFO, il recevait toujours "/index.html", et faisait donc une redirection vers "/" tout le temps.... d'où la boucle

C'est maintenant corrigé.

Merci à Rock-Mantique de m'avoir mis sur cette piste, et merci à Koogar de m'avoir ouvert les yeux sur RewriteRule et consoeurs.

[KOogar]

Le rewrite peut servir à faire des redirections mais on parlera avant tout de substitution d'URL pour la réécriture d'urls à la volées

...je suis content de t'avoir ouvert les yeux, (si peu vu l'etendu du domaine) mais ce qui est vexant, c'est de t'avoir fait 2 codes que tu n'a meme pas pris la peine de tester.

Bien heureux pour toi que tu es également trouvé une solution d'un autre coté..

++

[hibou57]

...je suis content de t'avoir ouvert les yeux, (si peu vu l'etendu du domaine) mais ce qui est vexant, c'est de t'avoir fait 2 codes que tu n'a meme pas pris la peine de tester.

Faut pas te vexer : comprend moi, c'est que je suis sur un mutualisé, et que donc j'évite de trop jouer pour ne pas poser de problème (jai déjà généré deux ou trois boucles de redirections qui ont duré plus d'une minute à chaque fois, je n'avais pas envie d'en rajouter).

Mais tu es sur un forum que tout le monde lis, et tu n'as pas répondu que pour moi : d'autres apprécieront ton code

Au passage, je me pose une question concernant les références. J'utilisais PATH_INFO, parce que pour concevoir les applications, je m'étais référé à la spécification CGI/1.1. Et dans cette spécification, il n'existe pas de REQUEST_URI (pas plus que dans le draft CGI/1.2).

Alors je me pose cette question : quel est le standard qui a introduit REQUEST_URI ? Est-ce une spécificité de Apache ? Je ne pense pas que ce soit introduit par PHP, parce que je n'utilise pas PHP, et pourtant j'ai cette variable dans mon environnement. Et comme elle ne fait pas parti des spécifications CGI, je ne vois pas d'autre source que Apache. Mais je peux me tromper : quelqu'un(e) peut m'éclairer ?

Marci

[KOogar]

parceque mon code il va forcement boucler ?

pour le reste de mon coté je comprend rien