Bonjour,

Est ce que quelcun aurait une idée ?

Depuis que mon plan 90 OVH a été mis a jour avec APache 2, la regle que j'utilsie dans le .htaccess ne fonctionne plus.
erreur 404.
pas de redirection...

je redirige toute slas pages se terminat par .html sur le fichier index.

RewriteEngine ON
RewriteRule ([a-zA-Z0-9-]*).html /index.php [L] (regle avant modif, hs)

RewriteRule ([a-zA-Z0-9-]*).html index.php [L] ( regle avec une modif conseillée par OVH , toujours HS)

RewriteRule ^([a-zA-Z0-9-]*)\.html$ /index.php [L] ( ne fonctionne pas non plus)

Merci !

Hello,

pour débugger ce genre de règle le plus simple est souvent d'activer les logs correspondant à mod_rewrite.


EDIT : désolé je suis un boulet, pas vu que tu étais en mutu...

Oui, c'est un peu bizarre car à part l'histoire du Multiviews le passage à Apache 2 ne devrait pas faire de différence.

Essaie avec ^(.*) index.php [L]
si le ReWriting est bien en route, tu dois avoir une erreur 500.

je viens d'envoyer ce .htaccess

RewriteEngine On
^(.*) index.php [L]

ca n'a eu aucun effet...
(je suis sur un mutualisé OVH Plan 90)

bon, je viens d'avoir la solution .. il y avait 1 caractère windows dans le .htaccess (^M)
j'ai passé notepad++ au format Linux et ca fonctionne. Surement une tolérance des anciennes version d'Apache qui n'est plsu tolérée !

Effectivement, c'est surprenant...
C'est surprenant que ça passait avant... car les ^M, Linux n'aime pas vraiment.
En tout cas, ta malheureuse expérience est intéressante.
Je vais contrôler mes htaccess car les autres plans vont suivre... ;-)

Je confirme que ca fonctionnait avant la migration vers Apache2.
Et je dois avoir le même pb sur un GP60 sur lequel j'avais abandonné l'usage de quelques redirections suite a la migration debut juillet vers APache2.
idem en local .. avec Wamp5.

Là tu rediriges aussi le fichier index.php, vers index.php..... pas terrible !
Ajoute cette ligne avant ta règle:


Et en ce qui concerne le ^M, c'est le carriage-return de fin de ligne sous Windows. Linux n'accepte que le LINEFEED.
Tu as dû éditer le fichier .htaccess sous Windows et a oublié de l'envoyer par ftp en mode TEXT (qui convertit les fins de lignes)

oui, j'ai cumulé les erreurs .. Mon FTP Fillezila propose le transfert en modes : automatique, ASCII, Binaire.
Meme en restant en mode "automatique" , une fois que mon editeur de texte a été mis au format Unix au lieu de Windows , le problème a été réglé.

Maintenant, je ne sais pas quel mode entre automatique, ASCII, Binaire est préférable ou pourrait retirer les caractères de controle Windows.

C'est moi qui lui avais conseillé cela, justement pour provoquer une erreur 500.
Comme cela n'avait aucun effet, cela ne pouvait signifier que 2 choses:
- le rewriting n'est pas en route
- les règles ne sont pas interprétées
et que donc cela ne servait à rien d'essayer toutes les syntaxes possibles et imaginables...
(c'était le deuxième raison...)

oui, Remi, c'est pas une boucle infinie qui fait planter le serveur ?

Si vous parlez d'un hébergement mutualisé OVH, faites attention car ils ont leur propre module qui n'est pas 100% mod_rewrite compatible !
Il évite notamment certaines erreurs 500 dues au bouclage "ad infinitum".

Oui, c'est une boucle infinie mais le serveur ne plante pas vraiment (heureusement...), il génère une erreur 500.


Ah bon ? De quelles erreurs 500 parles-tu ? Et que fait-il dans ce cas-là ?
Des boucles infinies, cela m'est arrivé d'en faire
et il m'a toujours servi une petite 500 (bien fraîche).

En ce qui concerne les règles sur les mutualisés ovh, il fallait par exemple écrire (sous apache 1.3.X)


au lieu de

(il y a un / de différent, et cela changeait tout)

@Remi: je n'ai pas l'exemple en tête, mais une recherche sur le Hub (ou sur le forum OVH) te permettra de vérifier qu'effectivement la réécriture d'URLs sur mutualisé OVH a ses règles propres, ou du moins "les avait" sous apache 1.3.x.

Pour apache2, essaie en ajouteant cette ligne en début du fichier .htaccess


Par défaut Apache2 vient avec le Multiviews activé, je suis à 99% sûr qu'il s'agit de la raison qui fait foirer ta réécriture (mais pas 100% )
.

Dan