Muse_stream Posté(e) le 27 janvier 2017 Partager Posté(e) le 27 janvier 2017 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 :) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 27 janvier 2017 Partager Posté(e) le 27 janvier 2017 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 !!) 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Muse_stream Posté(e) le 28 janvier 2017 Auteur Partager Posté(e) le 28 janvier 2017 (modifié) 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
pluton212+ Posté(e) le 28 janvier 2017 Partager Posté(e) le 28 janvier 2017 cd /var/log/httpd 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 28 janvier 2017 Partager Posté(e) le 28 janvier 2017 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 ... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Muse_stream Posté(e) le 28 janvier 2017 Auteur Partager Posté(e) le 28 janvier 2017 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 28 janvier 2017 Partager Posté(e) le 28 janvier 2017 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Muse_stream Posté(e) le 28 janvier 2017 Auteur Partager Posté(e) le 28 janvier 2017 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. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 28 janvier 2017 Partager Posté(e) le 28 janvier 2017 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 ... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Muse_stream Posté(e) le 28 janvier 2017 Auteur Partager Posté(e) le 28 janvier 2017 oh le boulet, manque de sucre, faut que je mange ... je voulais dire suis bien sous apache ... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fenrir Posté(e) le 28 janvier 2017 Partager Posté(e) le 28 janvier 2017 sudo tail -f /var/log/httpd/*.log 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Muse_stream Posté(e) le 28 janvier 2017 Auteur Partager Posté(e) le 28 janvier 2017 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 ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Muse_stream Posté(e) le 28 janvier 2017 Auteur Partager Posté(e) le 28 janvier 2017 (modifié) 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 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.