La réécriture d’URL récursive

1er septembre 2003, par Dan

Vous souhaitez vous affranchir des réécritures statiques ?
La limitation à 9 de la variable $N utilisée pour les références arrières vous cause un problème parce que vous avez trop de paramètres ?
Vous voulez une règle suffisamment générique pour digérer vos variables, quels que soient leurs noms ou l’ordre dans lequel elles sont invoquées ?

Qu’en est-il de la récursivité ?

Avant toutes choses, gardez à l’esprit que le flag [N] peut créer une boucle infinie s’il est mal utilisé. Nous vous suggérons de lire attentivement La réécriture des URL « à la volée » pour en comprendre le fonctionnement avant de vous engager dans la voie de la récursivité. Les bases de la réécriture d’URL avec le module Apache mod_rewrite ont été analysées dans ce précédent article.

Etude de cas

Imaginons que vos URLs aient à l’heure actuelle la forme suivante :

index.php?var1=valeur1&var2=valeur2&...&varN=valeurN

avec un nombre de paramètres variable selon les différentes invocations de votre script index.php

Imaginons toujours que vous souhaitez présenter au monde extérieur des URLs plus « propres » de la forme :

index-var1-valeur1-var2-valeur2-....-varN-valeurN.html

En dehors de leur aspect plus « esthétique », ces URLs présentent l’avantage supplémentaire d’être indexables par les moteurs de recherche (pour mémoire, Google n’indexe pas les URLs comprenant plus de 2 paramètres…)

Si vous ne souhaitez pas écrire une règle spécifique pour chaque cas qui peut se présenter, la récursivité est la seule issue possible.

Résolution du problème

L’analyse nous montre :
 que nous avons N couples de noms/valeurs à traiter, les valeurs pouvant être « vides » pour certaines variables.
 que les noms et les valeurs ne sont pas connus au moment d’écrire la règle.

Nous poserons une seule condition
 nos noms de variables ou valeurs ne pourront pas contenir le tiret (-) que nous choisissons comme séparateur. Si certaines de vos valeurs contiennent un tiret « - », il suffira d’adapter la règle en choisissant un autre caractère séparateur.

Voici les règles qui seront commentées ci-après :

RewriteEngine on RewriteRule index(-.+)-([^-]+)-([^-&]*)([^-]*)\.html index$1&$2=$3$4\.html [N] RewriteRule index-([^-]+)-([^-]*)(.*)\.html index.php?$1=$2$3 [L]

La première ligne « RewriteEngine on » devrait vous être familière, si ce n’est pas le cas retournez lire La réécriture des URL « à la volée », tout y est expliqué.

Pour décoder ce type d’URL, deux lignes suffisent.
 la première ligne va boucler sur elle même de manière à traiter un couple variable/valeur à la fois. Elle comprend 4 « blocs » que nous réécrivons à l’aide du mécanisme de « référence arrière » d’Apache (appelé « backreference » dans la documentation).
Cette boucle est contrôlée par le flag [N] en fin de règle. Ce flag donnant instruction au serveur Apache de recommencer les règles au début du fichier si la règle est vérifiée.
 La deuxième règle est triviale et ne devrait vous poser aucun problème de compréhension. Elle marquera la fin de la réécriture grâce au flag [L]

Attention aux boucles infinies

Comme le flag [N] causera un retour au début du fichier (à la première règle), il est de première importance d’éviter que cette règle soit précédée par toute autre pouvant interférer dans les réécritures. Gardez à l’esprit que chaque itération fera recommencer tout le processus à la première règle définie dans le fichier .htaccess, en injectant dans le moteur de réécriture l’URL sous la forme réécrite par la dernière itération, et non l’URL originelle. Une mauvaise règle peut donc entraîner une boucle infinie si une URL mal réécrite est présentée.

Dans notre exemple, chaque nom de variable sera comparé à une chaîne de longueur supérieure ou égale à 1 caractère, ne comprenant pas le caractère « - », raison pour laquelle nous utilisons la syntaxe ([^-]+).
Les valeurs pouvant consister en une chaîne nulle, nous utiliserons la notation ([^-&]*).L’ajout du caractère « & » dans notre chaîne est utile car c’est celui-ci qui marquera le début de la chaîne réécrite.

En quelques mots, nous nous attacherons à réécrire l’expression en commençant par la fin, et en progressant jusqu’à ce qu’il ne nous reste plus qu’un couple variable/valeur.

Réduit à un langage plus « humain », le premier argument de la règle 1 s’énoncerait :

On cherche une chaîne qui	En clair	Expression régulière	Var.
débute par	le mot « index »	index
suivi par	une chaîne d’au moins un caractère, débutant par un tiret, représentant la partie de l’expression restant à traiter	(-.+)	$1
suivi par	un tiret	-
suivi par	un premier groupe de caractères différents du tiret et non nul, contenant le nom de la variable	([^-]+)	$2
suivi par	un tiret	-
suivi par	un deuxième groupe de caractères différents du tiret, pouvant être nul,contenant la valeur de la variable et ne pouvant pas contenir le caractère « & »	([^-&]*)	$3
suivi par	un groupe facultatif de caractères, à l’exclusion du tiret, contenant la partie de l’expression déjà traitée	([^-]*)	$4
finit par	le littéral « .html »	\.html

Nous nous appuierons sur deux particularités des expressions régulières :
 les expressions sont évaluées de gauche à droite
 lorsque plusieurs chaînes correspondent à la règle, la chaîne la plus longue est sélectionnée.

Pour mieux visualiser le processus complet et les différentes itérations, procédons par étapes successives :
(les noms vN et valN ont été choisis arbitrairement pour simplifier l’écriture de l’exemple, mais n’ont aucune incidence sur la réécriture de l’URL)

Itération 1 – Règle 1

Pour cette première itération, l’URL présentée est l’URL originelle, montrée ci-dessus.
Selon les principes énoncés plus haut, la variable (référence arrière) $1 se verra attribuer la plus grande longueur possible. Les variables $2 et $3 prendront donc respectivement les chaînes v5 et val5.
La variable $4, supposée contenir la partie de l’expression déjà traitée, sera vide.
Les chaînes de début « index » et de fin « .html » seront réécrites sans modification. L’URL réécrite, sera donc représentée au moteur pour l’itération suivante.

Itération 2 – Règle 1

 

La différence principale par rapport à l’itération précédente est l’apparition de la chaîne déjà réécrite (en bleu) et son affectation à $4. Comme elle commence par le caractère « & » et que celui-ci a été explicitement exclus de la chaîne $3, il n’y a donc pas d’imprécision possible quant au début de $4.
L’expression est réécrite, et représentée pour la prochaine itération.

Itération 3 – Règle 1

 

La variable $4 se voit affecter une chaîne plus importante, alors que $1 est réduit d’autant.
Continuons le processus…

Itération 4 – Règle 1

 

Il nous reste toujours suffisamment de caractères pour vérifier la règle, car nous pouvons attribuer à $1 une chaîne non vide. Rappelons-nous que nous avons écrit la règle en imposant une chaîne d’au moins 1 caractère en début d’expression.
Nous voici donc pratiquement au bout de nos efforts…

Itération 5 – Règle 2

 

Cette fois, nous n’avons plus suffisamment de chaîne en début d’expression pour valider notre première règle.
Notre expression sera donc présentée à la règle suivante qui sera effectivement vérifiée. Cette règle comprend un flag [L], ce qui marque donc la fin de la réécriture.

Expression finale

C’est exactement ce que nous souhaitions, la deuxième règle nous a débarrassé de l’expression « .html » en fin de chaîne, et a modifié notre chaîne « index » en « index.php ? ».

Important !!

Comme pour toutes les règles de réécriture d’URLs, une analyse précise s’impose. Plus encore qu’avec des règles de réécriture simples, la récursivité mal appliquée peut imposer à votre serveur Apache une charge qu’il aura du mal à supporter. Le piège de la boucle infinie n’est jamais très loin, et un seul caractère mal placé peut vous y faire tomber. La sagesse impose donc de tester ces règles dans un sous répertoire de votre site, ou mieux encore, sur un serveur local.

Un dernier exemple

Quelle règle utiliser si on veut s’affranchir du mot index- en début de chaîne, par exemple pour réécrire :

varA-11-varB-12-varC-13.html en program.php?varA=11&varB=12&varC=13 ?

C’est simple :

RewriteRule (.+)-([^-]+)-([^-&]*)([^-]*)\.html $1&$2=$3$4\.html [N] RewriteRule ([^-]+)-([^-]*)(.*)\.html program.php?$1=$2$3 [L]

 

Comment ça marche ?

Le Round-Robin DNS de Google

1er septembre 2003, par Dan

Une des questions les plus fréquemment posées concernant les résultats de recherche sur Google tient à l’architecture même du « Roi des moteurs »

Google a réparti ses nombreux serveurs dans différents centres de données (datacenters) de par le monde.

Datacentres Google	( Google en change régulièrement )
www-ab.google.com	Sterling (Virginie, Etats-Unis)
www-cw.google.com	Palo Alto (Etats-Unis, Californie)
www-dc.google.com	Washington DC (Etats-Unis)
www-ex.google.com	Santa Clara (Californie, Etats-Unis)
www-fi.google.com	(Europe,Supposé en Finlande ??)
www-gv.google.com	Dublin (Europe Irlande)
www-in.google.com	Santa Clara (Californie, Etats-Unis)
www-sj.google.com	San Jose (Californie, Etats-Unis)
www-va.google.com	Herndon (Virginie, Etats-Unis)
www-zu.google.com	Zurich (Suisse)

Lorsque vous émettez une requête vers http://www.google.com (ou .fr, .be,.ch…), votre requête est redirigée vers l’un des centres de données Google selon des critères de géolocalisation et de charge de ces derniers.

Cela se fait très simplement au niveau des résolutions de nom faites par les serveurs DNS, qui vous feront pointer sur l’un des ces datacentres.

Lorsque vous interrogez les DNS pour le domaine google.com, vous remarquerez que le TTL (time to live) est de l’ordre de 5 minutes (environ). Cela signifie que toutes les requêtes que vous envoyez à Google durant cette période utiliseront la même adresse IP que celle retournée lors de la première interrogation.

Une fois ce laps de temps écoulé, l’adresse IP correspondant à Google dans votre cache DNS sera considérée comme expirée et une nouvelle résolution de nom sera faite. En clair, vous aurez alors 90% de chances d’être mis en communication avec un autre datacentre.

En quoi cela impacte les recherches ?

C’est simple, comme il est matériellement impossible de maintenir tous les datacentres parfaitement synchronisés, les bases de données de certains centres seront « plus à jour » que d’autres. Ce qui fait qu’en interrogeant Google, les résultats pour une même recherche peuvent varier à quelques minutes d’intervalle.

Les plus grosses variations se remarquaient lorsque Google faisait des mises à jour mensuelles de ses bases de données. Les résultats variaient tellement d’un datacentre à l’autre, qu’ils donnaient l’impression de danser… d’où le nom de la « Google Dance »

Cette « Google Dance » n’a plus lieu actuellement, comme Google est passé à une indexation en continu, mais des essais peuvent être effectués de temps à autre sur l’un des datacentres, ce qui refait danser Google pour quelques heures ou quelques jours, et met la communauté mondiale des webmasters en ébulition.

Mod_rewrite, ou la réécriture des URL « à la volée »

Découvrons le module Apache mod_rewrite

29 août 2003, par Dan

Une des fonctions les plus puissantes permises par le fichier .htaccess est la réécriture « à la volée » des URL.
Sur le site officiel Apache, le module mod_rewrite est présenté à raison comme le couteau suisse de la manipulation.
Comme dans notre article sur le fichier .htaccess, il est utile de préciser que certains hébergeurs n’ont pas activé le module de réécriture. Dans ce cas, vous n’avez malheureusement aucune possibilité de l’utiliser, à moins de casser le petit cochon en porcelaine qui traîne chez vous et changer d’hébergeur.

Si vous gérez votre propre serveur dédié, assurez-vous que le module mod_rewrite est activé en modifiant le cas échéant le fichier de configuration du serveur Apache (httpd.conf).
Vérifiez que les deux lignes suivantes ne soient pas mises en commentaire :

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

Si vous devez changer ces deux lignes, il vous faudra redémarrer Apache pour que vos modifications soient prises en compte.

On teste d’abord !

La meilleure manière de s’assurer que le module mod_rewrite est chargé est encore de consulter le phpinfo. La mention de mod_rewrite dans la section Apache/Loaded Modules reste la meilleure garantie.

Avant de se lancer plus loin dans les explications, voici comment tester si le module mod_rewrite est actif chez votre hébergeur. Comme pour toutes manipulations qui peuvent impacter le bon fonctionnement de votre site, nous vous conseillons de faire ces essais en période creuse, en évitant par exemple la période de « full crawl » de Google.

1. Créez un fichier html simple, nommez le « trouve.html ».
2. Modifiez le fichier .htaccess en y ajoutant les 3 lignes suivantes. Faites très attention à utiliser la syntaxe précise ou mieux, utilisez le copier/coller :

Options +FollowSymlinks
RewriteEngine on
RewriteRule   ^nexistepas.html$   trouve.html  [L]

Attention chez OVH – règles spécifiques

Pour les hébergments mutualisés OVH, il faut donner un chemin absolu (par rapport à la racine de votre site) pour le second argument. Cela devient donc /trouve.html ou /repertoire/trouve.html

Nous reviendrons plus tard sur l’explication de ces deux instructions

3. Télécharger le fichier .htaccess et le fichier trouve.html à la racine de votre site web, ou mieux encore dans un répertoire de test créé pour l’occasion. Laissez votre client FTP ouvert pour pouvoir enlever le fichier .htaccess au cas où cela ne fonctionne pas.
4. Lancez votre navigateur et entrez l’URL : http://www.votresite.com/nexistepas.html

Et là, deux solutions se présentent :

 Soit votre page test « trouve.html » s’affiche c’est parfait, le module est activé.
 Soit vous avez une erreur 404 ou encore plus probablement une erreur 500 et malheureusement il n’y a pas grand-chose à faire… si ce n’est retirer tout de suite le fichier .htaccess avec le client FTP (vous l’aviez bien laissé ouvert comme suggéré plus haut, non ?).
Il est possible que votre hébergeur ne vous permette pas d’ajouter le « FollowSymLinks » dans les options Apache (résolution des liens symboliques, l’équivalent des raccourcis de Windows).
Vous pouvez supprimer cette ligne sans problème.

Si vous êtes face à ce deuxième cas, vous comprendrez mieux pourquoi nous vous avons suggéré de choisir une période creuse ainsi qu’un répertoire de test. Nous ne pouvons que répéter ici que toute modification du fichier .htaccess peut fortement impacter le fonctionnement de votre site web. Heureusement, les problèmes rencontrés ne sont pas irréversibles et disparaissent avec la suppression du fichier ou des règles erronées. La prudence s’impose.

Quelques explications sur la règle précédente.

Dans les trois lignes de l’exemple ci-dessus, la première autorise le serveur Apache à suivre les liens symboliques dans ce répertoire. Son utilité permet de corriger un éventuel défaut de configuration dans le fichier httpd.conf.
La deuxième ligne est une instruction d’activation de la réécriture d’URL. Quelles que soient les règles de réécriture que vous voulez mettre en place, de la plus triviale à la plus complexe, l’instruction « RewriteEngine on » devra toujours être insérée dans le fichier .htaccess.
Elle donne simplement au serveur Apache l’instruction de lancer le moteur de réécriture.
La troisième ligne est la règle de réécriture proprement dite, analysons la plus en détail :

RewriteRule	ce mot-clé introduit toute règle de réécriture, il est indispensable
^nexistepas.html$	c’est la première partie de la règle, celle qui determine la chaîne de caractères que le module devra rechercher pour la réécrire. Elle contient deux caractères spéciaux marquant le début (^) et la fin ($) de la ligne
trouve.html	la chaîne par laquelle il faudra remplacer celle trouvée à l’étape précédente. En règle générale, elle correspond au nom d’un fichier existant réellement dans votre espace Web.
[L]	Un flag (drapeau) signifiant que cette règle est la dernière à appliquer dans ce cas ( L = last = dernier ) et que le module ne doit plus rechercher à réécrire cette chaîne.

Ce premier exemple est bien évidemment trivial mais vous servira de base à l’établissement de toutes les règles de réécriture que vous serez amené à rédiger.
Vous la trouvez trop simple ? Assurez-vous d’avoir parfaitement compris le mécanisme avant de passer aux étapes suivantes, cela va se corser !

Les pièges dans lesquels il ne faut pas tomber.

Nous l’avons déjà mentionné, mais jugeons utile de le répéter. La réécriture d’URL permet le meilleur comme le pire.
Imaginez 2 règles, la première réécrivant abc.html en def.html, la seconde réécrivant def.html en abc.html . Si aucune des deux règles ne comporte le flag [L], vous voilà face à une version informatisée du mouvement perpétuel. Vous avez créé une boucle de laquelle votre serveur ne pourrait pas sortir s’il n’avait ses propres mécanismes de sécurité.
L’aisance avec laquelle une règle mal écrite peut mettre un serveur « sur les genoux » est la raison principale de la non implémentation du module de réécriture chez certains hébergeurs.

Des règles plus utiles.

Il est clair que l’exemple précédent n’a pas de véritable utilité. Ce simple exemple aurait pu s’écrire beaucoup plus simplement avec une seule instruction « Redirect ».
Prenons un cas plus concret…
Les réécritures d’URL sont le plus souvent utilisées pour présenter aux visiteurs une URL plus mnémotechnique ou pour permettre à certains moteurs d’indexer des pages dynamiques avec de nombreux paramètres qu’ils n’auraient pas visité sans réécriture.
Pour les robots d’indexation, la raison en est simple.
Dans le cas d’une URL dynamique du type article.php?num=12 , un moteur ne peut pas déterminer s’il ne va pas tomber dans une boucle sans fin. Un script article.php mal écrit – volontairement ou non – peut l’entraîner vers une multitude de pages satellites ne différant que par leur URL. C’est pour la même raison qu’ils n’indexent pas les pages avec des identifiants de session PHP, une même page étant retournée au navigateur avec une multitude d’identifiants de session différents.

Vous avez un site sur lequel vous présentez un catalogue en ligne. Sur ce site, chaque article comporte 2 pages, par exemple une page commerciale et une fiche technique.
De plus, les informations concernant l’article sont extraites d’une base de données, en se basant sur le numéro d’article.
Les URL des deux pages de l’article 8125 seront donc sous la forme (si votre script se nomme article.php) :

http://www.votresite.tld/article.php?numero=8125&page=1
http://www.votresite.tld/article.php?numero=8125&page=2

Vous préféreriez, et cela se comprend, que vos visiteurs accèdent à cet article par :

http://www.votresite.tld/article-8125-1.html
http://www.votresite.tld/article-8125-2.html

Analysons point par point comment réécrire cette règle toujours simple.
Nous voyons dans ces URL qu’elles contiennent deux parties variables : le numéro d’article et le numéro de page, tout le reste étant fixe comme le nom du script et le nom des variables.
La règle s’écrirait comme ceci :

RewriteEngine on
RewriteRule ^article-([0-9]+)-([0-9]+)\.html$  article.php?numero=$1&page=$2  [L]

Cela vous semble compliqué ? Il n’en est rien, voici l’explication :

Nous ne reviendrons pas sur la ligne RewriteEngine on qui est, vous le savez, indispensable. Nous l’omettrons d’ailleurs de manière systématique pour la suite de nos exemples.

Nous retrouvons dans notre règle les parties constantes « article – - .html » et « article.php ?numero= &page= » que nous avons identifiées.
De même, les caractères de début (^) et fin ($) de ligne ont été expliqués précédemment.

Appliquons nous à remplir les blancs.

 Partie gauche de l’expression

Dans cette partie, nous trouvons deux fois une même chaîne de caractères « ([0-9]+) » qui est basée sur les expressions régulières (regular expressions) familières aux utilisateurs Unix/Linux.
Les parenthèses carrées [ ] déterminent un intervalle, donc [0-9] détermine l’intervalle des nombres « 0 » à « 9 ».
Le signe « + » qui suit immédiatement l’intervalle signifie « une ou plusieurs occurrence(s) de l’expression qui précède », notre intervalle [0-9] dans cet exemple.
Ce qui signifie qu’avec l’intervalle suivi du signe « + », nous sommes en mesure de matérialiser tout nombre entier supérieur ou égal à 0 , ce qui correspond bien à la forme de notre numéro d’article.
Enfin, les parenthèses qui entourent le tout « ([0-9]+) » donnent instruction au moteur de réécriture de grouper la chaîne trouvée et la stocker dans une variable interne parce que nous souhaitons l’utiliser plus tard. Apache stockera donc ces chaînes dans les variables $1, $2, … $n dans l’ordre dans lequel elles sont analysées, de gauche à droite et nous pourrons y faire référence dans la partie droite de notre règle.
Dans notre exemple, Apache aura stocké les chaînes « 8125 » dans la variable interne $1 et « 2 » dans la variable $2.
Le point décimal ayant une signification particulière dans les expressions, il est utile dans notre cas de le faire précéder par le caractère d’échappement « \. ». Nous verrons ceci plus en détail par la suite.

 Partie droite de l’expression

Une fois compris ce qui précède, elle est vraiment triviale à comprendre.
Dans l’expression « article.php ?numero=$1&page=$2 » les variables $1 et $2 sont remplacées respectivement par les chaînes « 8125 » et « 2 » ce qui nous donne bien l’URL avec les paramètres que notre script article.php s’attend à recevoir.
Le dernier élément « [L] » fait comprendre, comme expliqué précédemment que c’est la dernière règle qui s’applique pour cet élément.

Quelques expressions régulières à connaître :

.	n’importe quel caractère
[abcd]	n’importe lequel de cette liste de caractères
[^abcd]	tout caractère non compris dans la liste (autre que a, b, c ou d)
blanc|noir	alternative, soit « blanc », soit « noir »
+	Une ou N occurrence(s) de l’expression qui précède (N > 1)
*	Zéro ou N occurrence(s) de l’expression qui précède (N>0)
(texte)	Groupement permettant l’utilisation des références inverses ($1,… $n) Est aussi utilisé pour délimiter une alternative comme dans (blanc|noir)
	ancre de début de ligne
$	ancre de fin de ligne
\	permet d’échapper tout caractère qui suit et lui ôter sa signification particulière, par exemple \.

Quelques drapeaux (ou flags) utiles.

Voici quelques drapeaux utiles pour faciliter la maintenance d’un site :

[L]	Celui-ci vous semble familier, comme nous l’avons vu dans notre précédent exemple. Il mérite toutefois une précision. Lorsque le module de réécriture est actif, les règles sont lues séquentiellement et l’URL est comparée ligne à ligne avec le premier argument de celles-ci jusqu’à la dernière. Si une réécriture est effectuée, c’est la forme réécrite qui sera utilisée en entrée pour les règles suivantes. Le flag [L] permet de sortir prématurément de la boucle. Un autre exemple serait, en début d’une liste de règles :RewriteRule ^.*\.gif$  -  [L] RewriteRule ^.*\.jpg$  -  [L]
	Nous introduisons ici un nouveau concept, à savoir un second argument vide (ou presque, car il consiste en un seul caractère « - » ) . Cette règle particulière implique qu’il n’y a pas de réécriture, l’URL étant passée sans modification aucune. Elle signale au serveur Apache de passer toutes les URL d’images gif ou jpg sans réécriture, ni traitement successif.
[R] [R=code]	Dans ces deux formes une redirection est effectuée. Si l’argument code n’est pas précisé, une redirection 302 (déplacé temporairement) est effectuée. Si vous souhaitez faire savoir au navigateur/robot qu’une page a été remplacée définitivement, utiliser le code 301 comme dans : RewriteRule ^ancien\.html$ http://domaine.tld/nouveau.html [R=301,L] Dans ce cas précis, une réécriture « externe » s’impose (utilisation de http://…)
	Vous voyez ci-dessus que nous avons combiné deux flags en les séparant par une virgule.
[F]	Forbidden – interdit. Retourne un code 403, par exemple : RewriteRule ^secret.html$ – [F] ( pas de réécriture vu le deuxième argument – )
[NC]	NoCase, ou « insensible à la casse ». La règle suivante : RewriteRule  ^script\.php$  programme.php  [NC,L] S’appliquera aussi bien à script .php, SCRIPT.PHP ou ScRiPt .PhP
[G]	Gone. Cette page n’existe plus et retourne une entête http 410
[N]	Force l’analyse et l’exécution de toutes les règles en repartant du début de la liste. Ici encore, comme expliqué plus haut ([L]), c’est l’URL modifiée après exécution de la dernière règle qui est utilisée en entrée, et non l’URL originelle. Attention aux boucles infinies !!
[C]	Chain, chaînage avec la ou les règles suivantes jusqu’à la première règle ne se terminant pas par [C] Apache interprète ce flag comme suit : s’il y a réécriture (la règle est vérifiée), la règle suivante est exécutée avec la chaîne réécrite en entrée. Si la règle ne se vérifie pas, toutes les règles qui suivent jusqu’à la première ne comportant pas le flag [C] ne sont pas appliquées.
[QSA]	Query String Append. Rajoute le QUERY_STRING à la fin de l’expression, après la réécriture. A réserver pour la dernière règle de réécriture. Utilisée le plus souvent avec le flag [L], comme dans [QSA,L]

Cette liste n’est pas exhaustive, car il existe d’autres flags supportés. La liste complète est décrite dans la documentation du module mod_rewrite sur le site d’Apache.

Attention aux « répertoires virtuels »

Dans les exemples qui précèdent, nous avons effectué des réécritures qui n’impactaient pas l’arborescence apparente de vos pages, pour simplifier les exemples.

Si, au lieu de réécrire, en reprenant l’exemple précédent :
RewriteRule ^article-([0-9]+)-([0-9]+)\.html$  article.php?numero=$1&page=$2  [L]
nous utilisons
RewriteRule ^article/([0-9]+)/([0-9]+)\.html$  article.php?numero=$1&page=$2  [L]

L’URL apparente aurait la forme /article/8126/2.html au lieu de /article-8126-2.html
Dans ce cas, le navigateur « estime » que la page se trouve dans un répertoire /article/8126 qui n’a pas d’existence réelle sur votre site. Toute tentative de résolution de liens relatifs se fera donc à partir de ce répertoire inexistant et sera vouée à l’échec.

Pour éviter cela, deux solutions se présentent :

 Utiliser des liens absolus, ou mieux…
 Faire usage de la balise <base href="http://www.votresite.tld/repertoire/" > à mettre dans l'entête de votre page, entre <head> et  </head>

Les réécritures conditionnelles

Dans les quelques exemples qui précèdent, nous n’avons vu que des réécritures d’URL inconditionnelles, c.à.d. s’appliquant indépendamment du navigateur, de l’adresse IP ou du domaine émettant la requête. Nous allons maintenant passer à l’étape suivante, à savoir la réécriture sous conditions, à travers quelques exemples concrets.

Une page d’accueil différente selon le navigateur

RewriteCond  %{HTTP_USER_AGENT}  ^Mozilla.*
RewriteRule  ^/$    /complexe.html  [L]
RewriteCond  %{HTTP_USER_AGENT}  ^Lynx.*
RewriteRule  ^/$    /simple.html  [L]
RewriteRule  ^/$    /standard.html  [L]

Un nouveau mot-clé fait son apparition ici : « RewriteCond » ou « condition de réécriture ». La syntaxe est simple et de la forme : RewriteCond variable_testée valeur_de_comparaison

Dans l’exemple, testons si l’identifiant du navigateur (%{HTTP_USER_AGENT}) commence par Mozilla (^Mozilla) et est suivi par une chaîne quelconque. (.*)
Si cette règle est vraie, nous réécrivons le répertoire racine du site(^/$ signifie « début de ligne/fin de ligne » ou simplement / seul sur la ligne)) en page « complexe.html » et arrêtons nos réécritures [L]
Procédons de meme pour Lynx, qui se satisfera d’une page simple vu ses fonctionnalités réduites et enfin, si aucune des 2 règles précédentes ne s’applique, soit pour tous les autres navigateurs, redirigons les vers notre page « standard.html »

Protégeons nos fichiers images

Evitons maintenant que d’autres sites ne fassent un lien direct vers nos images, en nous détournant de la bande passante :

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.votredomaine.net/.*$ [NC]
ReWriteRule .*\.(gif|png|jpe?g)$ - [F]

C’est tout simple !

En mettant plusieurs conditions à la suite, un ET logique est effectué entre elles. Pour que la règle de réécriture soit effectuée, il faut donc que toutes les conditions soient vraies prises isolément. A la première condition FAUSSE, le moteur de réécriture branche directement après la règle et ne teste pas les conditions suivantes. Si un OU logique est nécessaire, on rajoute le drapeau [OR] en fin de ligne, en le combinant aux autres le cas échéant [NC,OR]

Dans notre exemple, on compare la variable HTTP_REFERER au domaine du site.
Les conditions s’énonceraient en clair « Si la variable HTTP_REFERER n’est pas vide et n’est pas égale au nom de domaine http://www.votredomaine.net/ suivi de n’importe quelle chaîne de caractères (même vide) en faisant abstraction de la casse [NC], alors… »

Notez que le point d’exclamation inverse le test et signifie donc « n’est pas ». Changez aussi le nom de domaine pour qu’il corresponde au vôtre.

La règle donne instruction de ne pas réécrire l’URL (grâce au signe – utilisé en second argument) mais de retourner une entête « 403 – Forbidden » pour tout fichier se terminant en .gif, .png , .jpeg et .jpg [F]

Le point d’interrogation suivant le « e » dans « jpe ?g » rend cette lettre facultative. Il y aura donc correspondance pour « jpg » et « jpeg ».

Un commentaire toutefois : Certains navigateurs permettent de masquer le HTTP_REFERER, et certains proxies ou firewall ne transmettent pas cette référence.
C’est la raison pour laquelle nous avons la première condition testant si HTTP_REFERER n’est pas vide. Sans cette règle, les visiteurs derrière certains firewall ou proxies ne verraient pas vos images.
Cette dernière limitation démontre bien qu’il n’est pas possible d’éliminer 100% des liens sauvages vers vos images puisqu’il suffit de masquer le HTTP_REFERER pour éviter l’interdiction. Une élimination de 95-98% des liens représente déjà une économie substantielle de bande passante.

Si vous souhaitez autoriser certains domaines amis à faire des liens directs, il suffit d’ajouter pour chacun d’eux une condition supplémentaire :

RewriteCond %{HTTP_REFERER} !^http://votredomaine.net/.*$ [NC]

Cet exemple permet d’accéder aux images dans le cas où votre domaine serait invoqué sans le sous-domaine « www ».

Débarrassons-nous des visiteurs indésirables

La condition s’écrira généralement sous une des formes suivantes :

RewriteCond %{REMOTE_HOST} ^badhost\.baddomain\.tld$
 teste le nom d’un ordinateur hôte spécifique

RewriteCond %{REMOTE_HOST}  baddomain\.tld$
 teste le domaine complet (se termine par…, notez l’absence du caractère ^)

RewriteCond %{HTTP_USER_AGENT}   ^VilainRobot.*
 teste le nom du robot indésirable (HTTP_USER_AGENT commence par la chaîne « VilainRobot »)

RewriteCond %{REMOTE_ADDR}  ^123\.45\.67\.12[5-9]$
 teste une plage d’adresses IP (de 123.45.67.125 à 123.45.67.129 inclus)

Pourquoi éviter certains robots ?

Tous les robots ne sont pas bénéfiques pour votre sites.
Certains d’entre-eux sont des aspirateurs de site, d’autres collectent les adresses email et finissent par remplir votre boîte aux lettres de courrier non-sollicité (spam). Ils ont tous une caractéristique commune : utiliser les resources de votre serveur sans vous apporter aucun visiteur « utile ».
Tous ces robots « indélicats » ne respectent pas le protocole d’exclusion représenté sous la forme du fichier « /robots.txt ».

Soyez très attentifs dans l’écriture de vos règles d’exclusion, par exemple la condition : RewriteCond %{HTTP_USER_AGENT}   Bot est beaucoup trop générique et vous priverait du passage de GoogleBot, ce qui n’est sûrement pas ce que vous souhaitez.

Un exemple concret :

RewriteCond %{REMOTE_HOST}  \.laurion\.(com|net)$  [OR]
RewriteCond %{REMOTE_HOST} \.cn$ [OR]
RewriteRule ^.*$   -   [F]

La première condition interdit toute visite en provenance de laurion.com et laurion.net. Cela peut sembler un peu brutal comme règle mais ce robot ne respectant pas le protocole d’exclusion et ne se gênant pas pour « pomper » plus de 100 pages/minutes nous n’avons pas vraiment eu envie de mettre de gants le concernant.

Elle aurait pu s’écrire, en se basant sur le HTTP_USER_AGENT :

RewriteCond %{HTTP_USER_AGENT}  ^IPiumBot   [OR]

La deuxième condition élimine encore plus radicalement tout visiteur provenant de Chine.
Ces règles et conditions ne sont que des exemples et ne sont pas dictées par une quelconque xénophobie de la part de l’auteur. Elles ont néanmoins contribué à réduire de manière significative la bande passante utilisée.

Comment tester différents HTTP_USER_AGENT ?

Il est bien évident que nous ne pouvons pas installer tous les USER_AGENT possible, la liste est trop longue. Certains navigateurs tels que Opera permettent de choisir le USER_AGENT sous lequel on « butine »…
Certains sites Web permettent de vérifier les entêtes reçues très facilement, par exemple http://www.wannabrowser.com/
Cette page, combinée avec une analyse approfondie de vos fichiers logs, vous permettra de mettre au point vos conditions de réécriture pour les différents visiteurs de votre site.

Pour effectuer vos tests, il est judicieux de créer un répertoire temporaire sur votre site, dans lequel vous mettrez un fichier index.html et le fichier .htaccess sur lequel vous travaillez.
Une fois votre fichier .htaccess mis au point, déplacez le dans le répertoire que vous voulez protéger, ou à la racine de votre site.

Des règles différentes selon les répertoires

Un fichier .htaccess placé dans un répertoire régit l’accès à ce répertoire ainsi qu’à tous les sous-répertoires et fichiers de celui-ci.
Vous pouvez bien sûr avoir plusieurs fichiers .htaccess dans des répertoires différents, selon les différentes protections ou réécritures que vous désirez appliquer.

Dans le cas d’un fichier .htaccess situé dans un sous-répertoire du site, les règles et conditions remplacent celles définies à l’échelon supérieur.
Si votre souhait est d’ajouter des règles de réécriture à celles du niveau supérieur au lieu de les remplacer, ajoutez la ligne suivante juste après le « RewriteEngine on » :

RewriteOptions inherit

Cette instruction spécifie que toutes les règles et conditions définies au niveau supérieur sont héritées, en supplément à celles que vous rajouterez dans le fichier .htaccess

Le fichier .htaccess

29 août 2003, par Dan

Cet article a pour but de vous faire découvrir le fichier .htaccess et son utilisation pour améliorer votre site web.

Ce simple fichier texte [1] vous permet d’ajuster finement certains paramètres de votre serveur Apache tels que les redirections, les réécritures d’URL, les redirections et les restrictions d’accès.

Cette puissance permet le meilleur comme le pire. Même si la syntaxe des règles du fichier .htaccess est souvent triviale, la moindre faute dans celles-ci se traduira le plus souvent par la redoutée « erreur 500″ [2].

L’une des utilisations les plus répandues de ce fichier est l’affichage d’une page 404 [3] personnalisée, beaucoup plus utile que celle procurée par défaut par votre navigateur favori.

Note aux utilisateurs FrontPage Lorsque les extensions FrontPage sont installées, un fichier .htaccess est créé à la racine du site. Il faut donc être très prudent et éviter d’écraser ce fichier, faute de quoi les extensions FrontPage ne fonctionneraient plus sur votre site. De même, avant toute modification, une sauvegarde du fichier originel est utile, car toute erreur dans ce fichier pourrait rendre l’entièreté de votre site inaccessible.

Votre hébergement permet-il son utilisation ?

C’est, bien sûr, la première question à se poser. Elle ne fait malheureusement pas partie de celles auxquelles on peut répondre simplement.
Si votre hébergement se fait sur un système Unix/Linux et que le serveur Web est de type Apache, le fichier .htaccess est supporté. Ceci ne veut malheureusement pas dire que votre hébergeur en autorise l’utilisation.
Le plus souvent, les hébergements gratuits ont cette fonctionnalité désactivée.

Si votre hébergeur vous permet de restreindre l’accès à certains de vos répertoires à l’aide d’un mot de passe, c’est en général à l’aide du fichier .htaccess, dans ce cas, tout va bien.

De deux choses l’une : soit vous téléchargez votre fichier .htaccess et tout fonctionne comme vous l’espériez, soit cela ne fonctionne pas et au pire vous obtenez une « erreur 500″. Dans ce cas, il ne vous reste plus qu’à retirer le fichier incriminé. Ce n’est pas bien dangereux, mais réservez vos essais à une période creuse. Le seul cas où un fichier .htaccess pourrait poser de réels problèmes est celui où le serveur utilise des extensions Microsoft FrontPage.
Ces dernières utilisent le fichier .htaccess et son écrasement les empêcherait à jamais de fonctionner.

Si vous n’aimez pas vivre dangereusement, le plus simple reste encore de demander à votre hébergeur ou à une connaissance ayant le même type d’hébergement que vous.

Pour effectuer vos tests, il est judicieux de créer un répertoire temporaire sur votre site, dans lequel vous mettrez un fichier index.html et le fichier .htaccess sur lequel vous travaillez. Une fois votre fichier .htaccess mis au point, déplacez le dans le répertoire que vous voulez protéger, ou à la racine de votre site.

C’est supporté ? Bien ! Restez avec nous !

Avant toutes choses, il faut arriver à créer ce fichier. Sous pratiquement tous les systèmes d’exploitation, cela se fait sans problème comme n’importe quel fichier texte. Windows peut toutefois ne pas accepter la création de ce fichier tel que souhaité. En effet, .htaccess est vu par Windows comme un fichier sans nom comportant une extension non standard. Si notepad ou votre éditeur favori ne vous permet pas d’enregistrer ce fichier avec le nom souhaité, sauvez-le comme htaccess.txt, vous le renommerez plus tard sur votre serveur à l’aide de votre logiciel de transfert ftp.
Attention : Une fois renommé, le fichier doit impérativement se nommer « .htaccess » (débutant par un point), sinon il sera sans effet.

Nous allons commencer notre découverte avec une fonctionnalité bien utile

La page d’erreur « sur mesure »

Comme tout internaute, vous avez déjà eu l’occasion de faire face à l’erreur la plus répandue, l’erreur 404. Cette erreur vient du fait que l’Internet est essentiellement mouvant, des millions de pages y apparaissent et disparaissent chaque jour.
Si un de vos visiteurs décide de mettre en favori l’une de vos pages pour y revenir plus tard, rien ne lui garantit que cette page sera toujours accessible à sa prochaine visite.
Vous pouvez à tout moment décider de la déplacer, de la renommer ou de la supprimer. C’est votre site, vous en avez le droit le plus absolu.

Que se passera-t-il lors du retour de ce même visiteur ? C’est simple : son navigateur fera une requête pour la page souhaitée, requête à laquelle le serveur répondra « pas trouvé ».
Dès la genèse du Web, les différents concepteurs ont bien intégré le fait que les utilisateurs seraient d’origines différents et qu’une page mentionnant ce laconique « pas trouvé » ne pourrait pas être exhaustive sur le plan linguistique. Ils ont donc défini des codes pour chaque type d’erreurs, laissant aux navigateurs le soin d’afficher le message dans la langue de l’utilisateur. D’où, dans ce cas précis, l’erreur communément appelée « erreur 404 ».

Pour éviter à vos visiteurs cette page peu esthétique, une seule ligne suffit dans le fichier .htaccess :

ErrorDocument  404  /mapage.html

Dès ce moment, toutes les requêtes pour des pages inexistantes recevront en retour la page mapage.html. Si vous êtes prévoyant, cette page pourrait présenter un plan de votre site qui évitera à votre visiteur de se sentir seul et abandonné de tous. Il faut bien sûr que ce fichier « mapage.html » existe à la racine de votre site sinon votre serveur ne saura plus où donner de la tête. Ne souriez pas, c’est arrivé à l’auteur de ces lignes.

D’une manière plus générale, l’instruction « ErrorDocument » s’écrit :

ErrorDocument  code-erreur  fichier

En plus de l’erreur 404, vous pouvez donc fournir des pages spécifiques pour les erreurs les plus fréquentes, par exemple :

401 - Autorisation Requise
400 - Mauvaise requête
403 - Interdit
500 - Erreur interne serveur

La restriction d’accès par mot de passe

Nous avons tous sur nos sites certains répertoires que nous souhaitons protéger des yeux indiscrets. Qu’il soit bien entendu ici, que la meilleure protection possible pour un document passe par la non publication sur le Web, quelle que soit le niveau de protection du serveur ou du répertoire.
Ceci est encore plus vrai s’il s’agit d’un hébergement mutualisé dont la gestion est assurée par un organisme indépendant. Ne stockez donc pas sur votre serveur Web d’informations dont la divulgation pourrait vous pénaliser.

Ces limitations étant exprimées, il est souvent utile ou dans certains cas indispensable d’avoir dans un répertoire des informations telles que le mot de passe d’accès à votre base de données ou les statistiques de fréquentation de votre serveur.
Dans le cadre des hébergements sur serveur Apache, il est aisé de soustraire certains répertoires à la curiosité du public. Cette fois encore, le fichier .htaccess est votre allié.

Le mode opératoire en est simple et s’appuie sur un deuxième fichier qui contiendra les noms et mots de passe des personnes autorisées à accéder au contenu du répertoire.

Dans le fichier .htaccess, saisissez les informations suivantes :

AuthUserFile /home/login/.htpasswd
AuthGroupFile /dev/null
AuthName "Acces Restreint"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>

Analysons de plus près ces quelques lignes :

AuthUserFile /home/login/.htpasswd
donne le répertoire dans lequel se trouve le fichier contenant les paires login/mot de passe des visiteurs autorisés. Notez bien qu’il ne s’agit pas d’une URL, mais bien d’un chemin d’accès depuis la racine du serveur.

L’usage veut que ce fichier soit souvent nommé .htpasswd, mais ce n’est pas du tout une obligation. Il est même conseillé d’utiliser un autre nom, le fichier sera d’autant plus difficile à trouver. Ne le mettez pas dans un répertoire qui fait partie du site mais placez-le plutôt en dehors de cette arborescence si vous en avez le choix.

Dans le système d’exploitation Unix/Linux, tous les fichiers dont le nom commence par un point décimal sont des fichiers cachés. Attention : caché ne signifie pas invisible, mais signifie plutôt qu’ils n’apparaissent pas dans les commandes les plus fréquentes si leur affichage n’est pas spécifiquement demandé.

AuthGroupFile /dev/null
permet de donner un droit d’accès à un ensemble d’utilisateurs faisant partie d’un même groupe et est rarement utilisée dans le cas de sites Web personnels. Dans l’exemple, le fichier « /dev/null » est l’équivalent Unix de « nulle-part » ou « pas de fichier spécifique »

AuthName "Acces Restreint"
est la chaîne de caractère qui apparaîtra dans la boîte de dialogue au moment de la saisie du nom et du mot de passe.

AuthType Basic
détermine le type d’authentification utilisé, dans notre cas l’authentification HTTP standard.

<limit GET POST> ... </limit>
détermine le type d’opérations permises. GET s’applique à la majorité des pages Web, PUT est utilisé par certains scripts ou éditeurs pour faire de l’upload sous protocole http. Il est important de mettre GET et POST en majuscule sur les dernières versions d’Apache.

require valid-user
signifie littéralement qu’un utilisateur valide est requis, à savoir un utilisateur pour le nom duquel une ligne existe dans le fichier .htpasswd. Une variante pourrait être :
require user pierre paul
pour limiter l’accès aux seuls utilisateurs pierre et paul

Le fichier .htpasswd

C’est très simple, pour chaque utilisateur autorisé ce fichier contient une ligne sous la forme « nom:mot de passe crypté » ou encore « pierre:saqKFoHV4rU.E »

La seule difficulté, pour autant que c’en soit une, étant de crypter le mot de passe. Il existe deux types d’approche différents :

 Vous avez accès a un shell Unix/Linux

htpasswd -c passwdfile username

Dans cette commande, « passwdfile » représente le chemin complet du fichier mot de passe souhaité, « username » est le nom de l’utilisateur.

 Pour tous ceux qui n’ont pas d’accès au shell unix, voici de quoi encrypter votre mot de passe (algorithme DES avec clé) :

Nom:
Mot de passe:
Clé:

La clé de deux caractères demandée permet de diversifier les mots de passe générés. Ces deux caractères constituent ce qu’on appelle le « sel » (salt) de l’encryptage. Vous voilà en mesure de restreindre l’accès à vos répertoires privés ou, pourquoi pas, de créer des répertoires réservés aux copains ou aux membres de votre famille.

Vous avez déplacé vos pages ?

Il est parfois nécessaire de déplacer certaines pages ou répertoires d’un site dans l’optique d’une restructuration. Ceci ne va pas sans poser quelques problèmes inhérents au changement d’adresse :
 la page n’est plus accessible pour les visiteurs qui l’ont mise dans leurs favoris.
 les références à cette page dans les moteurs de recherche et annuaires pointent vers l’ancienne adresse.

Dans ces deux cas de figure, plutôt que de présenter une page d’erreur personnalisée au visiteur, il est beaucoup plus élégant de le rediriger automatiquement vers la nouvelle adresse. Ici encore, le fichier .htaccess nous sera précieux.

Pour déplacer une page :
RedirectPermanent ancien.html http://www.domaine.tld/nouveau.html

Cette directive signale au navigateur que la page ancien.html a été renommée nouveau.html et renvoie l’entête correcte au navigateur pour signaler ce fait (entête 301 « déplacement permanent »). L’avantage de cette approche est que les robots d’indexation des différents moteurs apprendront que cette page a été déplacée et modifieront leur index pour refléter la nouvelle adresse. Dans le cas de Google, le PageRank [4] de l’ancienne page sera automatiquement transmis à la nouvelle page.

Pour déplacer un répertoire :
RedirectPermanent /ancien http://www.domaine.tld/nouveau/

Il est important de noter que dans le cas d’utilisation de la directive RedirectPermanent, la nouvelle adresse de page ou de répertoire doit être une URL complète.

Pour changer de nom de domaine :
RedirectPermanent / http://www.nouveaudomaine.tld/

redirigera la racine de l’ancien site vers le nouveau domaine.

Note : Seuls les moteurs de recherche ajusteront leur index pour refléter la nouvelle adresse. N’oubliez pas de demander aux annuaires de modifier leurs liens vers vos pages.

[1] Avec le protocole ftp, il est impératif de transférer le fichier .htaccess en mode texte et non en mode binaire, de manière à obtenir les caractères de fin de ligne appropriés au système d’exploitation du serveur. De même, l’édition en local devra se faire en mode texte.

[2] L’erreur 500 est une erreur interne au serveur, survenant le plus souvent lors de l’appel d’un module inexistant ou effectuant une opération illégale.

[3] L’erreur 404, ou « page inexistante », est l’erreur la plus fréquente sur le web.

[4] Indice de mesure de popularité d’une page utilisé par Google et noté sur une échelle de 0 à 10.

Monétiser son site web

(pour les Nuls)

7 avril 2009, par le-juge

Un site bien conçu, agréable à lire et bien positionné peut engendrer des revenus grâce à l’affichage de publicités. Il n’est pas question non plus de faire de votre site un panneau d’affichage en tout genre. Mais de cibler la publicité en rapport avec votre contenu.

Sans pour autant vous garantir la fortune de Bill Gates, vous trouverez ici quelques conseils de base pour vous aider à monétiser vos pages.
Avant de commencer vous devez d’abord comprendre l’argent ne pousse pas plus dans les arbres sur le web que dans la vie. Monétiser son site nécessite du travail, du temps et des efforts. La différence sur le web c’est le faible investissement de départ puisqu’il est possible de créer un blog ou un site web gratuitement. Pour le reste… c’est votre main d’œuvre.

• Principe de base (pour un site qui ne repose pas sur la vente de produits ou services)

« PAS DE VALEUR AJOUTEE = PAS D’AUDIENCE = PAS D’ARGENT »

Par « valeur ajoutée », il faut entendre tout ce que vous pouvez faire pour générer une audience sur votre site / blog.

Les Internautes ont l’embarras du choix, ils peuvent passer du temps sur une galaxie de sites. Ils ne le perdront pas sur un site Web qui ne leur donnent rien en retour (fun, connaissances, conseils, bons plans … peu importe).
 
Avant de penser à monétiser votre site Web, vous devez vous assurer que vous allez attirer et garder certains internautes avec un contenu intéressant. Votre site web doit devenir une “ressource”.
 
Vous n’avez peut être rien à vendre ou pas de service à offrir, mais vos connaissances peuvent intéresser quelqu’un. Vous êtes un bon cuisinier ! Partagez quelques recettes ! Vous avez hobby ?! Partagez-le avec nous …

• Que pouvez-vous faire avec votre site / blog ?

 
Tout ce que vous pouvez mettre en ligne, engendre des pages ou des posts qui vont être vus par les internautes et qui sont autant de potentiel pour générer des publicités. La sélection de la publicité que l’on va proposer sur votre site est faite à partir des thèmes abordés sur votre site. Si le sujet de votre site est le jardinage, vous allez intéresser les publicitaires qui veulent vendre des produits de jardin : Les accessoires, les gammes de produits de traitement des fleurs etc… De même si vous parlez d’informatique vous pourrez avoir des produits liés à ce thème : Des ordinateurs, mais aussi des loueurs de serveurs, etc… C’est pourquoi vous avez besoin du public.

• Les différentes possibilités pour afficher de la publicité sur votre site

 
L’affiliation : 

Est appelée plateforme d’affiliation la société qui va vous permettre par le biais d’un code à insérer sur votre site, d’afficher des publicités.
Est appelé éditeur, le webmaster qui affichera ces publicités sur son site, et donc sera rémunéré pour cette prestation. (vous lecteur de cet article)
Est appelé site marchand, le site qui va faire appel à une plateforme d’affiliation pour promouvoir ses produits et services en ligne.

La base de l’affiliation est de présenter des sites marchands à des sites éditeurs qui publieront de la publicité pour des produits et services.

Les éditeurs sont généralement payé à la commission sur la base des ventes ou des prospects qu’ils ont envoyés au site marchand. Les types de commissions les plus courantes sont CPV (coût par vente) et le CPA (coût par acquisition)

CPV (Coût par vente) : L’éditeur encaisse un pourcentage sur le prix des achats réalisés grâce à son site.

Exemple : Rémunération de 15% de commissions sur les ventes. Si un internaute achète pour 100 € via le lien sur lequel il a cliqué sur votre site, vous en qualité d’éditeur vous gagnerez 15 €.

CPA (coût par acquisition) L’éditeur perçoit une somme fixe pour chaque prospect qu’il envoie sur le site marchand.

Exemple : Un site marchand fixe un prix de 50 € pour chaque internaute qui fera une demande de devis sur son site. L’éditeur touchera 50 € par internautes qu’il enverra remplir une demande de devis.
Le model CPA est très utilisé par les compagnies liées a la finance. (Crédit, assurance)

Il existe de nombreuses plateformes d’affiliation en ligne en France, et chacunes d’entres elles comptent de nombreux programmes qui peuvent s’adapter à votre site / blog lié au sujet que vous traitez et donc à votre public.

A vous de voir dans ces plateformes quels seront les programmes susceptibles de faire de l’argent.

Quelques adresses de plateformes d’affiliation : Plublicidees.com , Affilinet , TradeDoubler , Zanox , Reactivpub .

Attention ! Certains marchands gèrent leurs propres programmes d’affiliation (sans passer par une plateforme). Vous serez parfois obligé de vérifier si un lien « affilié » ou « webmaster » apparait dans le footer du site pour lequel vous voulez faire de la promotion.

Google Adsense
 
Votre site fera parti du réseau Google et affichera des liens sponsorisés qui en général sont liés a la thématique du site. Google paie les webmasters sur une base de CPC (coût par click). :

CPC – Coût par Click, Google reverse une partie du prix de vente du click à l’éditeur.

Exemple : A chaque clic sur un lien figurant dans un encart « Publicité Google » présent sur votre site vous percevrez une commission allant de quelques centimes d’euros à 1 voire beaucoup.
 
A priori un webmaster qui cherche à rentabiliser son site via le programme Adsense aura besoin de plus de trafic pour générer un revenu correct que s’il participe a un programme d’affiliation bien choisi.

Pour plus d’informations vous pouvez vous inscrire à Google Adsense

ou

Poser vos questions dans le forum Webmaster-Hub
 

Bannieres (régies publicitaires) 
 
Les bannières sont un moyen de monétisation encore réservé au site à fort trafic (plusieurs milliers de pages vues par semaine au minimum), même si les régies ont fait des efforts pour s’adapter à un modèle économique en plein transformation : le web 2.0 (et au-delà…).

Les éditeurs sont généralement rémunérés au ”CPM » (coût par millier de bannières vues). Le CPM moyen observe sur internet est entre 2 € et 5€

CPM - : Chaque fois qu’une banniere placée sur le site est vue 1 000 fois, l’éditeur de ce site perçoit une commission qui est en moyenne entre : 2 et 5 euros.

Si vous souhaitez implémenter des bannières sur votre site pour gagner de l’argent, vous devez avoir un site ou réseau de sites qui bénéficie d’un assez grand volume de pages vues.

D’autres systèmes de paiement tels que CPA ou le CPC (voir modèle plus haut) ont été mis en place récemment. Quoiqu’il en soit il n’y a rien à perdre de contacter une régie.
 
De la même façon que les plates-formes d’affiliation, il y a beaucoup de régies publicitaires en ligne et de programmes différents. A vous de les consulter pour trouver ce qui correspond le mieux à votre site et son public.

Quelques Adresses de régies publicitaires : ValueClickMédia ,HORYSONclics , AdvertStream ,Adverline …
 
Vente de Liens
 
En tant que Référenceur, je recommande à mes clients de ne JAMAIS acheter de liens.

Google qui est le moteur de recherche ultra dominant en France (95% des parts de marché) a clairement annoncé que l’achat de liens est considéré comme de la manipulation des résultats et que les sites qui en achètent courent les mêmes risques que les sites qui en vendent. Une des grosses régies américaine a été blacklistée récemment.

Dans la plupart des cas, les webmasters reçoivent un montant fixe payé sur une base mensuelle pour chaque lien présent sur leur site web.

Le prix d’un lien peut aller jusqu’à 400$ par mois en fonction du thème du site de sa qualité et de son Page Rank. Certaines régies vous permettent fixer vous-même votre prix.

Quelques adresses de régie de vente de liens : Teliad , LinkLifft 

Spécial Blog
 
Si votre blog parle d’un sujet précis vous pouvez essayer le « Pay per review ».

Fondamentalement ce concept est un mélange entre Buzz Marketing et vente de liens. Les annonceurs payent entre 50 $ à 500 $ (en fonction de la qualité et du Page Rank du blog) pour la rédaction d’un article à propos de leurs produits ou services sur votre Blog.

Il existe des plateformes qui gérent les relations entre les annonceurs et les éditeurs.

Quelques adresses de régies  : eBuzzing , BuzzParadise . 

Quand puis-je attendre des revenus ?

Concernant les revenus, il n’y a pas de vérité absolue.
C’est très variable mais surtout en fonction de la qualité de votre site/blog, du secteur d’activité que vous couvrez et de l’importance de votre audience. Il y a des sites très important qui générent des revenus relativement modestes compte tenu des efforts de mise à jour et de maintenance du site. A contrario il y a des petits blogs assez médiocres mais qui traitent de sujets niches qui arrivent à faire beaucoup de bénéfice.

Il n’y a pas de recette miracle pour faire du chiffre d’affaire grâce à la publicité. Chaque méthode à ses avantages et ses inconvénients. Il vous appartient de choisir la méthode la plus adaptée à votre audience et du thème de votre site. Vous pouvez aussi tester plusieurs méthodes pour sélectionner celle qui vous convient le mieux. L’emplacement des encarts publicitaires est aussi un facteur à ne pas négliger.

Par exemple :

• Toujours mettre les publicités sur les pages les plus vues de votre site ou blog
• Avoir des encarts publicitaire en relation avec le sujet traité sur la page
• Mettre les liens sur les pages a plus fort Page Rank et de preference en haut et à gauche de la page

Pour plus d’information sur l’optimisation des encarts publicitaires sur votre site/blog il est possible de consulter les forums du Hub rubrique Promotion et Publicité Plus spécialisé dans la publicité pour les blogs vous pouvez trouver des informations intéressantes sur MonetiWeb 

Attention :

Ne pas oublier non plus, que les revenus généré par la publicité ne sont pas des cadeaux faits aux webmasters. Ce sont des revenus professionnels, et donc soumis à L’impôt et cotisations sociales. Vous trouverez quelques informations en lisant la publication de BZHCool : Déclarez vos revenus publicitaires, ou Auto-entrepreneur ce qu’il faut savoir.

Requête HTTP

Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Elle comprend:

• une ligne de requête: c’est une ligne précisant le type de document demandé, la méthode qui doit être appliqué, et la version du protocole utilisée. La ligne comprend trois éléments devant être séparé par un espace:
  • La méthode
  • L’URL
  • La version du protocole utilisé par le client (généralement HTTP/1.0)
• Les champs d’en-tête de la requête: il s’agit d’un ensemble de lignes facultatives permettant de donner des informations supplémentaires sur la requête et/ou le client (Navigateur,système d’exploitation,…). Chacune de ces lignes est composé d’un nom qualifiant le type d’en-tête, suivi de deux points (:) et de la valeur de l’en-tête
• Le corps de la requête: C’est un ensemble de ligne optionnel devant être séparé des lignes précédentes par une ligne vide et permettant par exemple un envoi de données par une commande POST lors de l’envoi de données au serveur par un formulaire

Une requête HTTP a donc la syntaxe suivante (<crlf> signifie retour chariot ou saut de ligne):

METHODE URL VERSION<crlf>

EN-TETE : Valeur<crlf>

.

.

.

EN-TETE : Valeur<crlf>

Ligne vide<crlf>

CORPS DE LA REQUETE

Voici donc un exemple de requête HTTP:

GET http://www.commentcamarche.net HTTP/1.0

Accept : text/html

If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT

User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)

Commandes

Commande	Description
GET	Requête de la ressource située à l’URL spécifié
HEAD	Requête de la ressource située à l’URL spécifié
POST	Envoi de données au programme située à l’URL spécifié
PUT	Envoi de données à l’URL spécifié
DELETE	Suppression de la ressource située à l’URL spécifié

En-têtes

Nom de l’en-tête	Description
Accept	Type de contenu accepté par le browser (par exemple text/html).
Accept-Charset	Jeu de caractères attendu par le browser
Accept-Encoding	Codage de données accepté par le browser
Accept-Language	Langage attendu par le browser (anglais par défaut)
Authorization	Identification du browser auprès du serveur
Content-Encoding	Type de codage du corps de la requête
Content-Language	Type de langage du corps de la requête
Content-Length	Longueur du corps de la requête
Content-Type	Type de contenu du corps de la requête (par exemple text/html).
Date	Date de début de transfert des données
Forwarded	Utilisé par les machines intermédiaires entre le browser et le serveur
From	Permet de spécifier l’adresse e-mail du client
From	Permet de spécifier que le document doit être envoyé si il a été modifié depuis une certaine date
Link	relation entre deux URL
Orig-URL	URL d’origine de la requête
Referer	URL du lien à partir duquel la requête a été effectuée
User-Agent	Chaîne donnant des informations sur le client, comme le nom et la version du navigateur, du système d’exploitation

 

Réponse HTTP

Une réponse HTTP est un ensemble de lignes envoyé au navigateur par le serveur. Elle comprend:

• une ligne de statut: c’est une ligne précisant la version du protocole utilisé et l’état du traitement de la requête à l’aide d’un code et d’un texte explicatif. La ligne comprend trois éléments devant être séparé par un espace:
  • La version du protocole utilisé
  • Le code de statut
  • La signification du code
• Les champs d’en-tête de la réponse: il s’agit d’un ensemble de lignes facultatives permettant de donner des informations supplémentaires sur la réponse et/ou le serveur. Chacune de ces lignes est composé d’un nom qualifiant le type d’en-tête, suivi de deux points (:) et de la valeur de l’en-tête
• Le corps de la réponse: Il contient le document demandé

Une réponse HTTP a donc la syntaxe suivante (<crlf> signifie retour chariot ou saut de ligne):

VERSION-HTTP CODE EXPLICATION<crlf>

EN-TETE : Valeur<crlf>

.

.

.

EN-TETE : Valeur<crlf>

Ligne vide<crlf>

CORPS DE LA REPONSE

Voici donc un exemple de réponse HTTP:

HTTP/1.0 200 OK

Date : Sat, 15 Jan 2000 14:37:12 GMT

Server : Microsoft-IIS/2.0

Content-Type : text/HTML

Content-Lentgh : 1245

Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT

 

En-têtes de réponse

Nom de l’en-tête	Description
Content-Encoding	Type de codage du corps de la réponse
Content-Language	Type de langage du corps de la réponse
Content-Length	Longueur du corps de la réponse
Content-Type	Type de contenu du corps de la réponse (par exemple text/html).
Date	Date de début de transfert des données
Expires	Date limite de consommation des données
Forwarded	Utilisé par les machines intermédiaires entre le browser et le serveur
Location	Redirection vers une nouvelle URL associée au document
Server	Caractéristiques du serveur ayant envoyé la réponse

 

 

Les codes de réponse

Ce sont les codes que vous voyez lorsque le navigateur n’arrive pas à vous fournir la page demandée. Le code de réponse est constitué de trois chiffres: le premier indique la classe de statut et les suivants la nature exacte de l’erreur.

Code	Message	Description
10x	Message d’information	Ces codes ne sont pas utilisés dans la version 1.0 du protocole
20x	Réussite	Ces codes indiquent le bon déroulement de la transaction
200	OK	La requête a été accomplie correctement
201	CREATED	Elle suit une command POST, elle indique la réussite, le corps du reste du document est sensé indiquer l’URL a laquelle le document nouvellement créé devrait se trouver.
202	ACCEPTED	La requête a été acceptée, mais la procédure qui suit n’a pas été accomplie
203	PARTIAL INFORMATION	Lorsque ce code est reçu en réponse à une commande GET, cela indique que la réponse n’est pas complète.
204	NO RESPONSE	Le serveur a reçu la requête mais il n’y a pas d’information a renvoyer
205	RESET CONTENT	Le serveur indique au navigateur de supprimer le contenu des champs d’un formulaire
205	PARTIAL CONTENT	Il s’agit d’une réponse à une requête comportant l’en-tête range. Le serveur doit indiquer l’en-tête content-Range
30x	Redirection	Ces codes indiquent que la ressource n’est plus à l’emplacement indiqué
301	MOVED	Les données demandées ont été transférées a une nouvelle adresse
302	FOUND	Les données demandées sont à une nouvelle URL, mais ont cependant peut-être été déplacées depuis…
303	METHOD	Cela implique que le client doit essayer une nouvelle adresse, en essayant de préférence une autre méthode que GET
304	NOT MODIFIED	Si le client a effectué une commande GET conditionnelle (en demandant si le document a été modifié depuis la dernière fois) et que le document n’a pas été modifié il renvoie ce code.
40x	Erreur dûe au client	Ces codes indiquent que la requête est incorrecte
400	BAD REQUEST	La syntaxe de la requête est mal formulée ou est impossible à satisfaire
401	UNAUTHORIZED	Le paramètre du message donne les spécifications des formes d’autorisation acceptables. Le client doit reformuler sa requête avec les bonnes données d’autorisation
402	PAYMENT REQUIRED	Le client doit reformuler sa demande avec les bonnes données de paiement
403	FORBIDDEN	L’accès à la ressource est tout simplement interdit
404	NOT FOUND	Classique! Le serveur n’a rien trouvé à l’adresse spécifiée. Parti sans laisser d’adresse …
50x	Erreur dûe au serveur	Ces codes indiquent qu’il y a eu une erreur interne du serveur
500	INTERNAL ERROR	Le serveur a rencontré une condition inattendue qui l’a empéché de donner suite à la demande (Comme quoi il leur en arrive des trucs aux serveurs …)
501	NOT IMPLEMENTED	Le serveur ne supporte pas le service demandé (on ne peut pas tout savoir faire …)
502	BAD GATEWAY	Le serveur a reçu une réponse invalide de la part du serveur auquel il essayait d’accéder en agissant comme une passerelle ou un proxy
503	SERVICE UNAVAILABLE	Le serveur ne peut pas vous répondre à l’instant présent, car le trafic est trop dense (Toutes les lignes de votre correspondant sont occupées veuillez rappeler ultérieurement)
504	GATEWAY TIMEOUT	La réponse du serveur a été trop longue vis à vis du temps pendant lequel la passerelle était préparée à l’attendre. (Le temps qui vous était imparti est maintenant écoulé …)

Plus d’informations

Pour plus d’informations sur le protocole HTTP, le mieux est de se reporter à la RFC 1945 expliquant de manière détaillée le protocole :

• RFC 1945 traduite en français
• RFC 1945 originale