Url Rewrite ne fonctionne pas ...

[Muse_stream]

Hello, 

Alors que je tente de ressusciter quelques sites Web en profitant de l'hébergement possiblement sur le NAS, je ne parviens pas faire fonctionner l'url rewriting.

Entre autres erreurs, la dernière que j'ai est : 

Internal Server Error

J'ai placé le .htaccess à la racine du site (dossier avec l'index, etc).
Et le code est je crois assez standard (j'ai essayé sans le SetEnv PHP_VER 5 n'étant pas sûr qu'il s'appliquait à la config du nas)  : 

Citation

Options +FollowSymlinks

RewriteEngine on

RewriteBase /
RewriteRule ^post-([0-9]+)\.html$ post.php?thisone=$1  [L]
RewriteRule ^index-([0-9]+)\.html$ index.php?page=$1  [L]
RewriteRule ^contact-([0-9]+)\.html$  contact.php?id=$1  [L]
RewriteRule ^([0-9a-zA-Z_-]+)\.html$ $1.php [QSA,L]
SetEnv PHP_VER 5

Une idée ?

Merci :)

[Fenrir]

Sans les logs difficile de t'aider.

Tu test bien avec apache et pas nginx

Active le ssh, passe root (sudo -s) et va dans le dossier /var/log/httpd, tu devrais y trouver les messages d'erreurs avec plus de détails

nb : les htaccess c'est à éviter (ce n'est pas moi qui le dit, mais la fondation apache !!)

[Muse_stream]

les url sont tout de même plus sympas avec un rewrite :/  

avec phpinfo() ça devrait pas marcher aussi ?  si oui, le fait est que je ne trouve aucune info sur un mod_rewrite installé ... ce qui expliquerait que ça ne fonctionne pas ...  

:( je sais pas comment aller dans le dossier httpd une fois connecté ...  j'ose à peine demander (j'ai cherché un peu sur internet mais pas trouver de commande évidente)

 

 

Modifié le 28 janvier 2017 par Muse_stream

[pluton212+]

cd /var/log/httpd

 

[Fenrir]

Il y a 1 heure, Muse_stream a dit :

les url sont tout de même plus sympas avec un rewrite :/  

Aucun rapport avec le fait d'utiliser un .htaccess, les gens l'utilisent pour faire ça car ils ne pas pas capable de programmer correctement leurs applications ou parce qu'ils n'ont pas les moyens de corriger des mauvais choix d'architecture logiciel (oui, les développeur de Wordpress, Joomla, ...  font des erreurs et/ou doivent faire avec les erreurs des précédentes versions).

C'est comme ceux qui utilisent rewrite pour passer du http au https, c'est de l'ignorance (pour ne pas dire de l'incompétence). Même chose pour mod_php, ça ne devrait jamais être utilisé.

On trouve des centaines d'erreurs comme ça sur le Web et elles sont relayées de sites en sites.

À toutes fins utiles, pour qu'un .htaccess fonctionne il faut 3 choses :

• utiliser un serveur Apache (pas IIS, pas Nginx, pas Cherokee, pas Lighthttp, ...)
• autoriser son usage dans la conf du serveur apache
• correctement écrire les instructions apache dans le fichier htaccess

nb : les .htaccess, y compris ceux utilisant rewrite fonctionnent sur un syno (j'ai vérifié)

Il y a 2 heures, Muse_stream a dit :

phpinfo() ... mod_rewrite

Si je regardes sous le capot de ma voiture je ne vois pas de références aux panneaux de circulation, et bien là c'est la même chose.

phpinfo c'est pour php, mod_rewrite c'est pour apache

---------------------

Citation

Les fichiers .htaccess ne doivent être utilisés que si vous n'avez pas accès au fichier de configuration du serveur principal. L'utilisation des fichiers .htaccess ralentit le fonctionnement de votre serveur HTTP Apache. Il est toujours préférable de définir les directives que vous pouvez inclure dans un fichier .htaccess dans une section Directory, car elles produiront le même effet avec de meilleures performances.

Quand doit-on (ne doit-on pas) utiliser les fichiers .htaccess ?

En principe, vous ne devriez utiliser les fichiers .htaccess que lorsque vous n'avez pas accès au fichier de configuration du serveur principal. Par exemple, la fausse idée selon laquelle l'authentification de l'utilisateur devrait toujours être faite dans les fichiers .htaccess est très répandue. Il est aussi souvent avancé, ces dernières années, que les directives de mod_rewrite doivent être définies dans les fichiers .htaccess. Ceci est tout simplement faux. Vous pouvez configurer l'authentification des utilisateurs au niveau de la configuration du serveur principal, et c'est en fait cette méthode qui doit être privilégiée. De même, les directives de mod_rewrite fonctionneront mieux, à de nombreux égards, dans le contexte du serveur principal.

Les fichiers .htaccess ne devraient être utilisés que dans le cas où les fournisseurs de contenu ont besoin de modifier la configuration du serveur au niveau d'un répertoire, mais ne possèdent pas l'accès root sur le système du serveur. Si l'administrateur du serveur ne souhaite pas effectuer des modifications de configuration incessantes, il peut être intéressant de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces modifications par le biais de fichiers .htaccess. Ceci est particulièrement vrai dans le cas où le fournisseur d'accès à Internet héberge de nombreux sites d'utilisateurs sur un seul serveur, et souhaite que ces utilisateurs puissent modifier eux-mêmes leurs configurations.

Cependant et d'une manière générale, il vaut mieux éviter d'utiliser les fichiers .htaccess. Tout élément de configuration que vous pourriez vouloir mettre dans un fichier .htaccess, peut aussi être mis, et avec la même efficacité, dans une section <Directory> du fichier de configuration de votre serveur principal.

Il y a deux raisons principales d'éviter l'utilisation des fichiers .htaccess.

La première est liée aux performances. Lorsque la directive AllowOverride est définie de façon à autoriser l'utilisation des fichiers .htaccess, httpd va rechercher leur présence dans chaque répertoire. Ainsi, permettre l'utilisation des fichiers .htaccess est déjà en soi une cause de dégradation des performances, que vous utilisiez effectivement ces fichiers ou non ! De plus, le fichier .htaccess est chargé en mémoire chaque fois qu'un document fait l'objet d'une requête.

Notez aussi que httpd doit rechercher les fichiers .htaccess dans tous les répertoires de niveau supérieur, afin de rassembler toutes les directives qui s'appliquent au répertoire courant (Voir la section comment sont appliquées les directives). Ainsi, si un fichier fait l'objet d'une requête à partir d'un répertoire /www/htdocs/exemple, httpd doit rechercher les fichiers suivants :

/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/exemple/.htaccess

En conséquence, chaque accès à un fichier de ce répertoire nécessite 4 accès au système de fichiers supplémentaires pour rechercher des fichiers .htaccess, même si aucun de ces fichiers n'est présent. Notez que cet exemple ne peut se produire que si les fichiers .htaccess ont été autorisés pour le répertoire /, ce qui est rarement le cas.

La seconde raison d'éviter l'utilisation des fichiers .htaccess est liée à la sécurité. Si vous permettez aux utilisateurs de modifier la configuration du serveur, il peut en résulter des conséquences sur lesquelles vous n'aurez aucun contrôle. Réfléchissez bien avant de donner ce privilège à vos utilisateurs. Notez aussi que ne pas donner aux utilisateurs les privilèges dont ils ont besoin va entraîner une augmentation des demandes de support technique. Assurez-vous d'avoir informé clairement vos utilisateurs du niveau de privilèges que vous leur avez attribué. Indiquer exactement comment vous avez défini la directive AllowOverride et diriger les utilisateurs vers la documentation correspondante vous évitera bien des confusions ultérieures.

Notez que mettre un fichier .htaccess contenant une directive dans un répertoire /www/htdocs/exemple revient exactement au même que mettre la même directive dans une section Directory <Directory "/www/htdocs/exemple"> du fichier de configuration de votre serveur principal :

Fichier .htaccess dans /www/htdocs/exemple :

Contenu du fichier .htaccess dans /www/htdocs/exemple

AddType text/example ".exm"

Section de votre fichier httpd.conf

<Directory "/www/htdocs/example">
    AddType text/example .exm
</Directory>

Cependant, la perte de performances sera moindre si vous définissez cette directive dans la configuration de votre serveur principal, car cette dernière ne sera chargée qu'une seule fois au moment du démarrage du serveur, alors qu'elle le sera à chaque accès dans le cas d'un fichier .htaccess.

L'utilisation des fichiers .htaccess peut être entièrement désactivée en définissant la directive AllowOverride à none :

AllowOverride None

source : https://httpd.apache.org/docs/2.4/fr/howto/htaccess.html

 

Citation

mod_rewrite doit être considéré comme un dernier recours, lorsqu'aucune alternative n'est possible.

source : https://httpd.apache.org/docs/2.4/fr/rewrite/avoid.html

 

...

 

 

 

[Muse_stream]

Il y a 2 heures, pluton212+ a dit :

cd /var/log/httpd

 

Merci, 

J'obtiens genre ça ?_?   (je savais pas quoi mettre après, alors vague souvenir de dos, j'ai mis "dir" ?!)

 

Citation

xxxxxxxxxxxx@xx:~$ cd /var/log/httpd
xxxxxxxxxxxx@xx:/var/log/httpd$
xxxxxxxxxxxx@xx:/var/log/httpd$ dir
total 768
drwxr-xr-x  2 root   root   4096 Jan 28 14:51 .
drwxr-xr-x 11 root   root   4096 Jan 17 13:50 ..
-rw-rw----  1 system log   61594 Jan 28 15:03 apache22-error_log
-rw-rw----  1 system log    4968 Jan 28 14:55 apache24-error_log
-rw-r--r--  1 root   root 121509 Mar  6  2016 sys-cgi_log
-rw-r--r--  1 root   root 529610 Mar 26  2016 sys-error_log
-rw-rw----  1 system log   32549 Jan  4 22:20 user-error_log

 

Merci Fenrir pour les infos.  Bon, en soi, c'est pas dramatique si mes url affichent du .php et des "?"  mais j'aimerais quand même les virer.  Et le fait est que pour le moment ça ne marche pas chez moi.  Quant à phpinfo(), j'avais des doutes aussi, mais sur un mini tuto trouvé sur le web, ils disaient que ça afficherait si mod_rewrite était actif ... 

Chemin parsemé d'embûches :-/   ça fonctionnait bien quand c'était sur ovh en tout cas 

[Fenrir]

tail -f /var/log/httpd/*.log

puis test ta page

mais avant, vérifie que tu utilises bien apache et pas nginx (choix par défaut) dans webstation

[Muse_stream]

merci, suis bien sous nginx

Citation

$ tail -f /var/log/httpd/*.log
tail: cannot open ‘/var/log/httpd/*.log’ for reading: No such file or directory
tail: no files remaining
 

...  ?

j'ajouterai que si je supprime "Options +FollowSymlinks" en début de fichier, je n'ai pas le message d'erreur "internal server error".  Juste que l'url rewriting ne fonctionne pas davantage.

[Fenrir]

il y a 4 minutes, Muse_stream a dit :

merci, suis bien sous nginx

Il y a 2 heures, Fenrir a dit :

À toutes fins utiles, pour qu'un .htaccess fonctionne il faut 3 choses :

• utiliser un serveur Apache (pas IIS, pas Nginx, pas Cherokee, pas Lighthttp, ...)

il y a 9 minutes, Fenrir a dit :

mais avant, vérifie que tu utilises bien apache et pas nginx

...

[Muse_stream]

oh le boulet, manque de sucre, faut que je mange ...

je voulais dire suis bien sous apache ... 

[Fenrir]

sudo tail -f /var/log/httpd/*.log

[Muse_stream]

Citation

xxxxxxx:~$ sudo tail -f /var/log/httpd/*.log
Password:
tail: cannot open ‘/var/log/httpd/*.log’ for reading: No such file or directory
tail: no files remaining

bon bon, je vais finir par me faire une raison :)

bizarre quand même, parce que un peu partout ailleurs ça a l'air de marcher naturellement

sinon, je revérifie un peu tout : j'ai installé le paquet php 5.6 et pas le 7 => mais ça ne doit rien changer n'est-ce pas ?

 

[Muse_stream]

hm ... y a un fameux truc qui m'échappe mais par dépit, j'ai commencé à élaguer mes quelques lignes du .htaccess pour ne garder que ça : 

Citation

RewriteEngine on
RewriteRule ^post-([0-9]+)\.html$ post.php?thisone=$1  [L]
RewriteRule ^index-([0-9]+)\.html$ index.php?page=$1  [L]
RewriteRule ^contact-([0-9]+)\.html$  contact.php?id=$1  [L]
RewriteRule ^([0-9a-zA-Z_-]+)\.html$ $1.php [L]

et bien sûr ... ça marche 

no comment, j'ai passé des heures sur le sujet
merci à vous d'avoir essayé de m'aider !!

 

je sais plus où me mettre 

 

Modifié le 28 janvier 2017 par Muse_stream