de l'interet des sites index.php?rub

Euh, tu te melange un peu, les 2 ne font pas du tout la meme job.
MultiViews

est utilise quand Apache ne trouve pas ton fichier, il va alors chercher un
autre fichier semblable qui a presque le meme nom. De plus ta page
bonjour.fr.html, ou bonjour.es.html, etc...

C'est bien ce qui me semblait, MultiViews c'est la « negotiation » d'Apache.
mod_rewrite c'est pour réécrire une URL en utilisant des expressions
régulières.

Je dirais meme plus, tous les pages finis par etre forcement dynamique.

En effet même une page statique, HTML, sera modifiée « dynamiquement » par
les développeurs durant toute la durée de vie du projet :). On peut aussi
parfaitement avoir une page dynamique qui s'occupe simplement de lire et
d'afficher des pages statiques, « prégénérées » (atchoum ^^).

JM

Si tu fais le site tout seul pt pas, mais avec une equipe de developpement
de 10 personnes, il se peut que qqun fasse des conneries et met un fichier
data.txt dans le repertoire public. et de plus certains hosts ne permet pas
de securiser des repertoire.

Mais de toute façon il pourrait y avoir les mêmes problèmes avec une
page PHP/HTML ordinaire.

Euh!!! je ne vois pas.

Je te cite : "il se peut que qqun fasse des conneries et met un
fichier
data.txt dans le repertoire public."

C'est pas possible quand on travaille avec des pages séparées ça ?
Il va falloir que tu m'explique ça, je comprend peut-être mal ce dont
tu veux parler...

Par rappport à "Les URLs sympas ne changent pas"
Là je ne comprend vraiment pas ! Personnelement, je serais plus porté
à modifier une URL en utilisant des fichiers ordinaires qu'en
utilisant un script qui fait des includes.

Justement c'est pour ca les page include, on ne doit jamais faire ca.

???

Euh, tu te melange un peu, les 2 ne font pas du tout la meme job. MultiViews
est utilise quand Apache ne trouve pas ton fichier, il va alors chercher un
autre fichier semblable qui a presque le meme nom. De plus ta page
bonjour.fr.html, ou bonjour.es.html, etc... doivent tous exister.
Mod_rewrite ne marche pas du tout pareil, il modifie le url en un format
avec ? et & genre http://domain.com/page.php/id/2/name/Savut pourrait
devenir http://mondomain.com/page.php?id=2&name=Savut pour le server. De
plus Mod_rewrite tu peux specifier comment il modifie le url, et pas
multiviews. J'espere tu comprend mieux comment ca marche la.

Le seul intérêt de Multiview dans ce cas, c'est de cacher l'extention
PHP.
On pourrait faire la même chose en renommant les .php en .xyz et les
associer au module PHP. Le but c'est soit de cacher que c'est un
script PHP (pour la sécurité) ou bien de permettre un changement de
langage sans changer les URL.

Quant à la variable PATH_INFO, elle peut servir pour reproduire un
comportement
semblable à celui de mod_rewrite. Comme tu dis, on peut s'en servir
pour
utiliser http://domain.com/page.php/id/2/name/Savut au lieu de
http://mondomain.com/page.php?id=2&name=Savut.
Mais c'est seulement une alternative à mod_rewrite (que je n'ai jamais
utilisé
d'ailleurs, mais je crois que je comprend le principe).

Finalement, je dirais que la seule chose dont je suis sûr d'un site
web que je fais, c'est qu'il va toujours y avoir une section avec une
page qui varie.

Je dirais meme plus, tous les pages finis par etre forcement dynamique.

Mais je ne sais pas d'avance où elle sera, donc faire un simple
include(header) et include(footer) ne me convient pas, car je ne
pourrai plus faire de changement majeur sans retoucher tous les
fichiers.

Euh!!! voyons donc, on fait ca justement pour eviter de retoucher a tout les
fichiers.

Oui... j'avais commencé à écrire une réponse à ça, mais disons que tu
as raison ;) C'est toujours possible de s'arranger d'une manière ou
d'une autre.
Je trouve juste que ça donne plus de trouble avec plusieurs include()

Pt c'est moi qui t'a mal compris :), en fin de compte, je pense que nous
nous eloignons pas mal du sujet. Tellement que je ne sais pas si la
premiere personne a recu une reponse convenable. Pour ce qui est des
principe de programmation web ou de configuration, je ne fait que donner moi
points de vue. A vous de faire votre bout de chemin...

Je suis pour une centralisation des traitements dans des includes
Je suis pour les mod_rewrite pcq c'est pratique
Je suis pour les page avec ID (avec cle primaire seulement), mais svp
envoyez aussi des nom de la page avec, meme si ce n'est pas necessaire. Ex:
page.php?id21&titre=Musique+Francais, meme si la variable titre n'est pas
utile.

Euh, juste pour te repondre, PATH_INFO, c'est different le principe car tu
dois faire le traitement dans tout tes pages php pour transformer le url en
utilisant des bouts de code php... A part t'a decouvert une configuration
magique... :D

Savut

Euh, juste pour te repondre, PATH_INFO, c'est different le principe car tu
dois faire le traitement dans tout tes pages php pour transformer le url en
utilisant des bouts de code php... A part t'a decouvert une configuration
magique... :D

Peut-être pour toi mais moi comme j'utilise une seule page avec un
include, je le fais juste une fois :P

C'est une idee, au fond ca revient a la meme chose, c'est juste que
mod_rewrite c'est Apache qui fait ce job, alors que toi tu le fais dans du
php. C'est etrange, je n'ai jamais pense a faire ca, ce serait ben utile
pour un site qui n'ont pas access a mod_rewrite. Essaie de decouvrir
mod_rewrite, ca te simplifiera un peu plus la vie.

Savut

"Jean-Pascal Houde" <jhoude@tuxfamily.org> wrote in message
news:2969ecd6.0402101304.21accfd7@posting.google.com...

Euh, juste pour te repondre, PATH_INFO, c'est different le principe car
tu

dois faire le traitement dans tout tes pages php pour transformer le url
en

utilisant des bouts de code php... A part t'a decouvert une
configuration

magique... :D

Peut-être pour toi mais moi comme j'utilise une seule page avec un
include, je le fais juste une fois :P

Bonjour,

Je ne comprend pas certains arguments que plusieurs personnes ont
exposés contre cette façon de faire.

Nb : je n'ai pas de temps à perdre à prendre position, il n'y a pas plus
d'arguments pour que contre, c'est une méthode de développement point
barre. En revanche :

Tout d'abord, je ne vois pas en quoi ça pourrait être un problème de
sécurité. Il faut seulement s'assurer que les paramètres envoyés sont
corrects et ne permettent pas de récuperer une page qui devrait être
privée...

Oui, justement : ne permettent pas de récupérer une page "privée". C'est
bien là le problème. Tu as écrit un script en espérant qu'il soit sur un
serveur avec register_globals=Off et dans un sous répertoire protégé par
un .htacess et manque de pot la machine de production fonctionne en On
avec Netscape Entreprise serveur donc pas de .htaccess comme prévu, les
droits sont mauvais etc... bref, c'est le boxon simplement parce qu'on a
pas codé de manière sécurisée générique.

Donc quand on programme avec des stubs de ce genre (stub = concentrateur
ou aiguilleur ou multiplexeur si on préfère) il est préférable d'adopter
l'une des deux méthodes suivantes :

- chaque fichier inclus est autonome dans ses vérifications de
cohérence. Seuls les fichiers faisant appel à des instructions type
echo, print, number_format... peuvent avoir des injections de variables
potentielles.
OU
- chaque fichier ne fait que définir une fonction qui est appelée avec
les bons arguments à la ligne du dessous.

Mais de toute façon il pourrait y avoir les mêmes problèmes avec une
page PHP/HTML ordinaire.

Tout à fait mais l'effet pervers est qu'on *peut* oublier que le script
inclus *peut* être appelé en direct dans l'URL dans certaines
conditions, alors que ce n'est pas ce qu'on a codé. Si si fait une
rimbambelle de script autonomes, on a aucune excuse.

Bref, comme d'habitude, il n'y a pas de méthode universelle, il faut
être conscient de ce que l'on fait. Comme qui dirait, il faut être
"aware" ;-)

De toute façon, que chacun fasse ce qui lui tente ! ;o)
Amen. Ite Missa Est.

a++
JG