vrobin
-
Compteur de contenus
25 -
Inscrit(e) le
-
Dernière visite
Messages postés par vrobin
-
-
Le fichier ne pose pas de problème si je commente les 2 dernières lignes. A partir du moment où j'en décommente une des 2 alors je rencontre le problème de chargement.
Merci de votre aide.
-
Bonjour,
J'avais un site sur un hégergement mutualisé (apache1) avec des fichiers htaccess.
J'ai migré vers un serveur dédié avec apache2. Et j'ai un problème avec un des fichiers htaccess.
=> Pas d'erreur 404 ou 500 mais un problème de chargement de page qui ne se termine jamais.
C'est un fichier htaccess à 4 lignes :
RewriteEngine On
RewriteRule ^article-([0-9]+)-([0-9]+)-(.*)-(.)*\.html$ index.php?id=$1&id_art=$2&type_rubrique=$3 [L]
RewriteRule ^blog-([0-9]+)-([0-9]+)*\.html$ index.php?id=$1&num_page=$2 [L]
RewriteRule ([^-]+)*-(.+)*\.html$ index.php?sous_domaine=$1&mail=$2 [L]
RewriteRule (.+)*\.html$ index.php?sous_domaine=$1 [L]Si je supprime le fichier htaccess, la page se charge correctement.
Si je mets le fichier htaccess sans les 2 dernières lignes, la page se charge toujours correctement.
Si je mets le fichier complet (avec les 2 dernières lignes), le chargement de la page ne se termine jamais.
Est-ce que quelqu'un aurait une idée ?
Merci d'avance
-
Le verdict est tombé : le problème venait bien de mon fichier htaccess (le 1er) !!
Depuis hier soir, je l'ai inactivé et notre CPU est revenue à la normale et n'a pas connu de pic !
Depuis Google a terminé ce qu'il voulait et il n'apparaît plus dans les processus...
Avant de l'inactiver, je l'avais corrigé selon les conseils de Dan... Merci Dan pour cette réponse ! C'est tordu quand même que les fichiers htaccess ne fonctionnent pas de la même manière sous mutualisé et sous dédié surtout que les redirections fonctionnaient bien ! Enfin il suffit de le savoir !...
Après cette correction, la CPU était remontée quand même...
Grâce aux logs apache, j'ai découvert un lien qui était incorrect : "http://domaine.com/recherche-abc/abm.html" mais mon dernier slash n'aurait pas dû être là !!
Forcément la règle suivante ne devait pas s'exécuter correctement :
RewriteRule ^recherche-(.+)*\.html$ index.php?mot_cle=$1 [L]
Du coup, google s'est mis à croire que recherche-abc était un répertoire et il s'est mis à chercher les pages http://domaine.com/recherche-abc/xxx.php qui n'existaient qu'au niveau supérieur (http://domaine.com/xxx.php). Un peu comme s'il faisait une boucle infinie...
Même après avoir corrigé ce lien, la CPU restait importante. C'est à ce moment que j'ai décidé d'inactiver le htaccess... Le temps de laisser passer les choses...
Là, je viens de le remettre à l'instant...
RewriteEngine on
RewriteRule ^dossier-([0-9]+)-(.)*\.html$ dossiers.php?source=$1 [L]
RewriteRule ^source-([0-9]+)-(.)*\.html$ source_web.php?source=$1 [L]
RewriteRule ^cabinet-([0-9]+)-(.)*\.html$ conseil.php?source=$1 [L]
RewriteRule ^logiciel-([0-9]+)-(.)*\.html$ logiciel.php?source=$1 [L]
RewriteRule ^recherche-(.+)*\.html$ index.php?mot_cle=$1 [L]Maintenant que google est parti, j'ai bien peur de ne pas voir tout de suite s'il reste des problèmes...
En tout cas, je savais que l'utilisation de htaccess était sensible mais à ce point là !!!
Je ne sais pas si le problème provenait de mon lien avec le slash ou s'il venait des slashs en trop dans le htaccess...
Si jamais le problème réapparaît, je vous tiendrais au courant...
Pour répondre à destroyedlolo, j'ai apache 1.3.37.
-
Suite...
La CPU est toujours à 100%...
Ce sont uniquement les processus "ouverts" par googlebot qui mange toute la CPU (ceux qui apparaissent en top).
Les autres processus httpd sont tout à fait normaux...
Que le processus soit en close_wait ou en established, ça ne change rien en fait...
On a donc carrément interdit l'accès à google pour voir et effectivement, notre CPU est redescendue à 0.xx%...
Par contre, google persiste à vouloir référencer notre site : on retrouve des erreurs dans les logs apache :
[Mon Sep 24 16:18:19 2007] [error] [client 66.249.66.174] client denied by server configuration: /home/toutpo/www/recherche-abc
De plus, cette page n'a jamais existé !! Donc nous ne voyons pas pourquoi il cherche y accéder depuis 4 jours...
Est-ce un pb de config apache ou bien est-ce dû à certains .htaccess que google n'arrive pas à interpréter ?
Dans httpd.conf :
<Directory />
Options Includes ExecCGI -MultiViews FollowSymLinks Indexes
AllowOverride All
</Directory>Les 2 htaccess qui sont sur le site :
RewriteEngine on
RewriteRule ^dossier-([0-9]+)-(.)*\.html$ /dossiers.php?source=$1 [L]
RewriteRule ^source-([0-9]+)-(.)*\.html$ /source_web.php?source=$1 [L]
RewriteRule ^cabinet-([0-9]+)-(.)*\.html$ /conseil.php?source=$1 [L]
RewriteRule ^logiciel-([0-9]+)-(.)*\.html$ /logiciel.php?source=$1 [L]
RewriteRule ^recherche-(.+)*\.html$ /index.php?mot_cle=$1 [L]ou
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.nomdomaine.com
RewriteCond %{HTTP_HOST} ^([^.]+).nomdomaine.com
RewriteRule ^$ http://nomdomaine2.com/blog/%1.html [L] -
J'ai la release OVH 7.2.
Voici le résultat de top :
92 processes: 86 sleeping, 5 running, 1 zombie, 0 stopped
CPU0 states: 99,1% user, 0,4% system, 0,0% nice, 0,0% idle
CPU1 states: 100,0% user, 0,0% system, 0,0% nice, 0,0% idle
Mem: 1030884K av, 1010168K used, 20716K free, 0K shrd, 203388K buff
Swap: 522104K av, 2820K used, 519284K free 515804K cached
28901 nobody 18 0 4908 4908 4668 R 37,2 0,4 49:13 httpd
29890 nobody 16 0 6712 6712 4864 R 36,2 0,6 0:08 httpd
7182 nobody 20 0 5144 5144 4800 R 34,2 0,4 38:32 httpd
16959 nobody 18 0 5440 5440 4860 R 33,2 0,5 33:34 httpd
12422 nobody 16 0 6604 6604 4904 R 32,3 0,6 11:10 httpd
22518 nobody 9 0 7332 7332 4896 S 1,9 0,7 10:37 httpd
11854 root 10 0 1044 1040 804 R 0,9 0,1 0:00 top
1 root 8 0 504 460 460 S 0,0 0,0 1:08 init
2 root 9 0 0 0 0 SW 0,0 0,0 0:00 keventd
3 root 19 19 0 0 0 SWN 0,0 0,0 0:00 ksoftirqd_CPU0
4 root 19 19 0 0 0 SWN 0,0 0,0 0:02 ksoftirqd_CPU1
5 root 9 0 0 0 0 SW 0,0 0,0 6:02 kswapd
6 root 9 0 0 0 0 SW 0,0 0,0 0:00 bdflush
7 root 9 0 0 0 0 SW 0,0 0,0 1:08 kupdated
8 root 9 0 0 0 0 SW 0,0 0,0 0:00 scsi_eh_0IPV6 n'est pas activé : Kernel : 2.4.33grs-bipiv-ipv4-32.
Pour le SWAP, y a-t-il un autre indicateur que "Swap: 522104K av" ?
Autre point remarqué depuis mon 1er post :
Charge CPU : 100% (même après avoir killé les processus googlebot à l'état CLOSE_WAIT)
Merci d'avance !
-
Bonjour,
Depuis vendredi, nous avons des ralentissements sur notre serveur dédié OVH.
En analysant de plus près, nous avons trouvé un nombre important de processus httpd à l'état CLOSE_WAIT qui ne se termine jamais...
Tous ces processus sont ouverts par l'adresse IP 66.249.66.174 qui est une adresse IP googlebot.
Ce problème a commencé vendredi matin vers 1h du matin (pendant notre sauvegarde quotidienne) et dans les logs apache, ça correspond au moment où googlebot est arrivé...
En redémarrant apache, ces processus disparaissent mais reviennent petit à petit... Nous devons donc redémarrer apache régulièrement pour que notre serveur continue de fonctionner correctement...
Nous n'avons pas trouvé de similitude avec les cas présentés dans les guides OVH... Est-ce que quelqu'un aurait une idée pour résoudre ce problème ?
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 6962/tcpserver
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 19413/couriertcpd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 28062/httpd
tcp 0 0 IP_SERVEUR:80 90.31.243.191:1499 SYN_RECV -
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 32662/perl
tcp 0 0 IP_SERVEUR:53 0.0.0.0:* LISTEN 30015/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 30015/named
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 28807/ncftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 14436/sshd
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 30015/named
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 8731/tcpserver
tcp 1 0 IP_SERVEUR:80 66.249.66.174:57066 CLOSE_WAIT 7431/httpd
tcp 0 0 IP_SERVEUR:80 90.31.243.191:1206 TIME_WAIT -
tcp 1 0 IP_SERVEUR:80 66.249.66.174:63473 CLOSE_WAIT 2274/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:48369 CLOSE_WAIT 27909/httpd
tcp 0 0 IP_SERVEUR:80 90.31.243.191:1205 TIME_WAIT -
tcp 1 0 IP_SERVEUR:80 66.249.66.174:46530 CLOSE_WAIT 16959/httpd
tcp 0 0 IP_SERVEUR:80 66.249.66.174:48581 ESTABLISHED 27871/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:39635 CLOSE_WAIT 7182/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:57769 CLOSE_WAIT 17784/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:48289 CLOSE_WAIT 8875/httpd
tcp 0 0 IP_SERVEUR:80 90.31.243.191:1767 TIME_WAIT -
tcp 1 0 IP_SERVEUR:80 66.249.66.174:61107 CLOSE_WAIT 27270/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:38796 CLOSE_WAIT 27704/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:65165 CLOSE_WAIT 12289/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:59012 CLOSE_WAIT 28901/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:35995 CLOSE_WAIT 22518/httpd
tcp 0 0 IP_SERVEUR:80 195.101.141.123:3563 TIME_WAIT -
tcp 0 0 IP_SERVEUR:80 195.101.141.123:3565 ESTABLISHED 25484/httpd
tcp 0 0 IP_SERVEUR:80 195.101.141.123:3564 ESTABLISHED 17110/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:61545 CLOSE_WAIT 25139/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:43369 CLOSE_WAIT 4730/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:35692 CLOSE_WAIT 12422/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:64621 CLOSE_WAIT 10336/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:34401 CLOSE_WAIT 541/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:57664 CLOSE_WAIT 13566/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:34395 CLOSE_WAIT 30711/httpd
tcp 0 0 IP_SERVEUR:80 195.101.141.123:2347 ESTABLISHED 12383/httpd
tcp 0 0 IP_SERVEUR:80 195.101.141.123:2348 ESTABLISHED 8979/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:64292 CLOSE_WAIT 12423/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:43324 CLOSE_WAIT 9073/httpd
tcp 0 0 IP_SERVEUR:80 195.101.141.123:1351 ESTABLISHED 30180/httpd
tcp 0 0 IP_SERVEUR:80 195.101.141.123:1352 ESTABLISHED 4548/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:60941 CLOSE_WAIT 26234/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:50692 CLOSE_WAIT 15319/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:55323 CLOSE_WAIT 19116/httpd
tcp 1 0 IP_SERVEUR:80 66.249.66.174:55583 CLOSE_WAIT 26569/httpd
udp 0 0 0.0.0.0:55690 0.0.0.0:* 30015/named
udp 0 0 IP_SERVEUR:32781 IP_SERVEUR:514 ESTABLISHED 32662/perl
udp 0 0 0.0.0.0:10000 0.0.0.0:* 32662/perl
udp 0 0 IP_SERVEUR:53 0.0.0.0:* 30015/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 30015/namedMerci d'avance.
Valérie
-
Oui, j'ai eu confirmation par OVH que même en passant par le DNS du dédié, ça ne fonctionnera pas !!
"Le Wildcard DNS n'est pas réalisable sur nos DNS, mais meme si vous mettez un dedié avec un wilcard DNS sur l'iP du mutualisé, notre configuration pour apache ne pourra pas vous convenir. Ce service n'est pas réalisable à ce jour."
J'ai bien peur de devoir passer sur un hébergement dédié...
En tout cas, je remercie les personnes qui ont essayé de m'aider !
-
Merci !!
Mais malheureusement non, mon nomdomaine1 est hébergé sur un mutualisé... Tout le problème est là !
Si OVH avait accepté les wildcard pour les hébergements mutualisés :
- j'aurais juste ajouté
*.nomdomaine2.com A adresseIPmutualisé
OU *.nomdomaine2.com CNAME nomdomaine2.com
dans les zones DNS de nomdomaine2.com sur le manager OVH
- j'aurai ajouté un multidomaine sur nomdomaine1.com pour que nomdomaine2.com pointe sur nomdomaine1.com/test/
Ca aurait suffit...
mais comme là je ne peux pas écrire *.nomdomaine.com A ou CNAME xxx dans le manager OVH, j'ai essayé de passer par le serveur DNS de mon dédié (qui héberge d'autres sites qui n'ont rien à voir).
Du coup, je cherche à lui dire que :
nomdomaine2.com => adresse IP hébergement mutualisé de nomdomaine1.com
et que www.nomdomaine2.com et *.nomdomaine2.com doivent pointer au même endroit que nomdomaine2.com.
J'ai tenté de le faire avec ces lignes :
nomdomaine.com. IN SOA nsxxxxx.ovh.net.
IN NS nsxxxxx.ovh.net.
IN A IPserveurMutualisé
www IN CNAME nomdomaine.com
* IN CNAME nomdomaine.commais ça ne fonctionne pas...
Quand je teste mes DNS via DNS Stuff : j'ai un WARNING sur le CNAME Lookup :
WARNING. Your web site (www.nomdomaine2.com) has a CNAME record pointing to nomdomaine2.com.nomdomaine2.com.. That by itself is confusing, but acceptable. However, the CNAME record in this case causes an extra DNS lookup, which will slightly delay visitors to your website, and use extra bandwidth.
En WWW Record, j'ai :
Your www.nomdomaine2.com A record is:
www.nomdomaine2.com. CNAME nomdomaine2.com.nomdomaine2.com. [TTL=38400]
-
Merci captain Torche pour ta réponse !
J'ai quand même poursuivi mes tests... Je vais faire un petit récapitulatif des actions effectuées :
Dans le manager OVH
sur le nomdomaine2.com
Serveur DNS :
nsxxxxx.ovh.net
sdns1.ovh.net
Zones DNS :
.nomdomaine2.com A adresseIPmutualisé
www.nomdomaine2.com CNAME nomdomaine2.com
sur le domaine1.com
j'ai ajouté un multidomaine : nomdomaine2.com .com /www/test/
et www.nomdomaine2.com .com /www/test/
Sur le dédié
Au niveau du serveur BIND, j'ai créé une zone primaire pour mon domaine nomdomaine2.com.
Mon fichier /var/named/nomdomaine2.com.hosts contient les lignes suivantes :
nomdomaine2.com. IN SOA nsxxxxx.ovh.net.
IN NS nsxxxxx.ovh.net.
IN A IPserveurMutualisé
www IN CNAME nomdomaine2.com
* IN CNAME nomdomaine2.comJe n'ai rien fait pour configurer sdns1.ovh.net.
Résultat
nomdomaine2.com pointe bien sur nomdomaine1.com/test/
Par contre www.nomdomaine2.com ou toto.nomdomaine2.com ne pointe vers rien du tout : j'ai l'erreur "impossible d'afficher la page "et un tracert m'indique "Impossible de résoudre le nom du système cible".
Ce que j'en déduis
Je pense que je passe bien par le serveur dédié pour résoudre le nomdomaine2.com sinon www.nomdomaine2.com fonctionnerait...
Ca voudrait dire que le CNAME dans mon fichier hosts du dédié n'est pas traité ?
Qu'en pensez-vous ?
-
N'ayant pas de réponse, je continue mes tests mais sans succès... Suis-je bien sur le bon forum ?
J'ai donc tenté d'ajouter *.nomdomaine2.com CNAME nomdomaine2.com dans le fichier nomdomaine2.com.hosts mais ça ne fonctionne pas du tout...
Est-ce que ça veut dire que ce que j'essaie de faire n'est pas possible ?
-
Suite...
En fait la redirection fonctionne bien => nomdomaine2.com pointe bien vers nomdomaine1.com/test/
Par contre, les wildcard ne fonctionne pas... Et ça me semble assez logique finalement puisque pour l'instant, je n'ai fait que dire :
*.nomdomaine2.com => adresse IP hébergement et comme sur le mutualisé je ne peux pas dire que *.nomdomaine2.com CNAME .nomdomaine2.com, il est perdu !
Il faudrait que je puisse ajouter un *.nomdomaine2.com CNAME nomdomaine2.com quelque part sur le serveur DNS de mon dédié mais est-ce possible ?
Je commence à me demander si ce que je cherche à faire est possible ?
Rappel du besoin :
Je cherche à trouver une solution pour faire en sorte que *.nomdomaine.com => nomdomaine.com sachant que je suis sur un serveur mutualisé OVH et que je ne souhaite pas migrer vers un dédié pour ce site. Mais j'ai quand même un serveur dédié chez OVH que je pourrais utiliser peut-être pour contourner les DNS du mutualisé ??
Merci d'avance !
-
Bonjour,
J'ai un site qui est hébergé sur un serveur mutualisé chez OVH (http://www.nomdomaine1.com).
(Et nous sommes contraints de rester en mutualisé pour ce site.)
Par contre, j'aurais besoin de l'option wildcard pour rediriger *.nomdomaine2.com vers nomdomaine1.com/test/
Or cette option wildcard n'est pas disponible sur les mutualisés OVH.
Je cherche donc un moyen de contourner le serveur DNS des mutualisés pour avoir cette possibilité.
Est-ce possible ?
J'ai à ma disposition un serveur dédié (pour d'autres sites). Je peux donc utiliser le serveur DNS de celui ci.
J'ai tenté ceci :
J'ai changé les serveurs DNS de nomdomaine2.com en mettant en serveur primaire le nom de ma machine dédiée.
Sur le dédié, j'ai déclaré ce nom de domaine et je lui dit de pointer sur l'adresse IP de l'hébergement mutualisé qui héberge mondomaine1.com.
J'ai ajouté mondomaine2.com en tant que multidomaine sur mondomaine1 en lui disant de pointer vers /www/test/.
Mais ça ne fonctionne pas... (Sans parler du widlcard bien sûr...)
Dans le manager, j'ai le message d'avertissement :
"Votre nom de domaine mondomaine2.com est configuré sur 'nsxxxxx.ovh.net, sdns1.ovh.net'. Votre hébergement dns est actif sur 'dns10.ovh.net, ns10.ovh.net'. Si et seulement si vous voulez utiliser cet hébergement, vous devez configurer votre nom de domaine sur 'dns10.ovh.net, ns10.ovh.net'."
Est-ce que quelqu'un saurait comment je peux résoudre mon problème ?
Merci d'avance !
-
C'était bien ça !
Tout fonctionne parfaitement !
Merci beaucoup !
-
Je te remercie beaucoup pour ton aide !!
Ca marche !
Enfin en partie seulement pour l'instant : domaine.fr fonctionne mais pas www.domaine.fr mais a priori, ça vient plutôt de mon paramétrage DNS...
Je n'avais configuré que domaine.fr (domaine.fr A xxx.xxx.xx.xx) => J'ai ajouté www.domaine.fr CNAME domaine.fr et je vais attendre demain pour voir si le pb vient bien de là...
Un grand merci donc !
-
Bonjour,
J'ai un serveur dédié chez OVH (avec Webmin Version 1.320 - Redhat Linux 7.2).
J'ai déjà installé plusieurs domaines sur mon serveur (en virtual host) avec une racine différente pour chaque domaine et ça fonctionne très bien (/home/sitexxx, /home/siteyyy...)
Aujourd'hui, je cherche à installer un nouveau domaine mais je ne veux pas créer un nouveau site : je veux qu'il pointe sur un site déjà installé sur mon dédié.
Pour résumé, je veux que le .com et .fr pointe tous les 2 sur /home/sitexxx/
Je l'ai déjà fait en mutualisé mais sur le dédié, j'avoue que je sèche !
Quelqu'un pourrait-il me guider ?
Merci d'avance.
-
J'aimerais bien comprendre aussi !!!
-
Ca y est ! Le problème est résolu !!
J'ai mis les droits 705 au lieu de 711 sur le répertoire contenant le .htaccess et là les 2 personnes m'ont répondu que ça marchait désormais !
Je n'arrive pas à comprendre pourquoi le lien avec les droits 755 sur le répetoire ne fonctionnait pas par contre ! Peut-être que la personne n'avait pas réellement testé tous les liens que j'avais proposé...
En tout cas, mon problème est résolu. Merci à ceux qui m'ont aidé !
-
Merci, ça pourrait être une piste ! Mais la 1ère personne à signaler le problème n'avait pas reçu les liens par mail... C'était en visitant le site et donc en cliquant sur les liens de la page http://www.certiferme.com/recette/livre_recette.php sans doute...
-
Suite à l'envoi d'une newsletter avec des liens vers des pages recettes, j'ai reçu un message d'une autre personne m'indiquant le même problème !
Ce n'est donc pas un problème isolé !
Merci de m'aiguiller vers des pistes à explorer !!
-
Merci !
Est-ce quelqu'un qui a le même système sur son site (url rewriting avec htaccess du même type que la règle que j'ai indiqué) pourrait me proposer des liens à tester ?
Je pourrais ainsi faire tester l'internaute mystère et je saurais si son problème vient de mon site ou bien de son environnement.
Est-ce qu'il pourrait s'agir d'un niveau de sécurité du navigateur particulièrement élevé ?
-
C'est le 1er internaute à me signaler le problème...
Vous pouvez tester, voici les liens que je lui ai transmis :
http://www.certiferme.com/recette/recette-..._en_gratin.html
http://www.certiferme.com/recette/recette....id_recette=1302
Normalement, vous arrivez sur la même page. L'internaute en question a un message Forbidden dans les 2 cas.
Voici le code du htaccess :
RewriteEngine on
RewriteRule ^recette-([0-9]+)-(.)*\.html$ /recette/recette.php?id_recette=$1 [L]et j'ai d'autres règles derrière du type :
RewriteRule ^recettes_cake\.html$ /recette/livre_recette.php?mots_cle=cake [L]
Je n'ai pas de fichier htaccess avec Deny From all.
Merci !
-
Bonjour,
J'ai mis en place un système de redirection afin d'améliorer notre référencement via l'url rewriting et htaccess.
Le but est : en allant sur "page_avec_le_titre_dans_le_lien-2.html" renvoie vers "page.php?id_page=2"
Pour moi, tout fonctionne très bien et pour la plupart des visiteurs également.
Mais hier, j'ai reçu un message d'un internaute m'indiquant qu'il avait un message "Forbidden you don't have permission to access xxx on this server".
Je suis hébergée chez OVH sur un 720plan. Je n'ai donc pas accès aux fichiers de config apache.
En regardant sur les forums, j'ai vu que cela pouvait être un problème de droit sur le répertoire ou que cela pouvait être du à l'option +FollowSymlinks.
Du coup, j'ai demandé à l'internaute de faire 3 tests pour moi :
- même lien (html) en ayant supprimer l'option FollowSymlinks dans le htaccess et avec les droits 711 sur le répetoire
- même lien (html) en ayant supprimer l'option FollowSymlinks dans le htaccess et avec les droits 755 sur le répetoire
- lien direct (php)
Aucun de ces 3 liens ne fonctionnent (même le dernier !) !! C'est comme si la présence du fichier htaccess dans le répertoire empêchait tout accès aux fichiers du répertoire pour cet internaute !!
Est-ce que quelqu'un aurait une idéé ?
Merci d'avance
Valérie
-
Merci pour ta réponse.
Ta solution semble simple mais je n'arrive pas à la faire fonctionner !
Voici mon code simplifié :
<TR>
<TD>
<DIV align="center">
<TABLE width="300" style="float:left">
<... contenu de mon tableau 1...>
</TABLE>
<TABLE width="300" style="float:left">
<... contenu de mon tableau 2...>
</TABLE>
</DIV>
</TD>
</TR>Il doit manquer quelque chose...
Merci d'avance !
Valérie
-
Bonjour,
Je souhaiterais mettre plusieurs tableaux les uns à la suite des autres sur une même ligne.
Avec display:inline, ça fonctionne sur IE mais pas sur firefox...
En parcourant les forums, j'ai vu qu'il fallait privilégier float à display.
Seulement, je voudrais centrer ma suite de tableaux sur la ligne et float:center n'existe pas...
Pour l'instant, je ne vois qu'un moyen, c'est d'imbriquer ma suite de tableaux dans un tableau mais j'aimerais bien éviter cette solution ! Je découvre le CSS et c'est quand même beaucoup mieux !
Si quelqu'un a une solution...
Merci d'avance.
Valérie
Un fichier htaccess qui empêche la page de se charger complètement
dans Fichier .htaccess et réécriture d'URLs
Posté
C'est bon, j'ai corrigé mon problème en modifiant mon expression régulière : j'ai remplacé (.+)* par (.*).