Bien que désactivé par défaut, la réécriture d’URL se met en place très facilement, via l’activation du « Mod_rewrite » d’Apache.

Tout d’abord, commencez par exécuter Wamp. Puis, via un clic gauche sur l’icône Wamp dans la barre des tâches ouvrez le fichier « httpd.conf » qui se trouve dans le dossier « Apache ».

Dans ce fichier recherchez la ligne

LoadModule rewrite_module modules/mod_rewrite.so

Et décommettez la en enlevant le « # » (dièse) qui se trouve devant, sauvegardez puis fermez le fichier.

Il faut maintenant redémarrer les services, via clic gauche sur l’icône de Wamp dans la barre des tâches puis « Restart all services », et ce, afin que la modification soit prise en compte.

La dernière étape est de s’assurer que le module « mod_rewrite » est bien chargé.Pour ce faire cliquez gauche sur l’icône de Wamp dans la barre des tâches et se rendre dans le menu « Apache » puis « Apache Modules ».

Descendez en bas de la liste, et si « Rewrite Module » n’est pas coché, cliquez dessus pour l’activer, puis redémarrer tous les services de Wamp.

Afin d’indiquer à Apache que nous souhaitons utiliser la réécriture d’URL sur un site, la ligne suivante doit être ajouté dans le .htaccess présent à la racine de ce dernier :

RewriteEngine on

La réécriture d’URL peux maintenant être utilisée sur vos différents projets web tournant sous Wamp Server.

L’objectif est ici de trier un tableau suivant la valeur d’une clé, cela s’adresse donc à un tableau multidimensionnel (deux dimensions pour être précis), pour ce faire nous utiliserons la fonction usort.

Prenons par exemple ce tableau et admettons que nous souhaitons le tirer par rapport aux valeurs de la clé « val »

$a = array(
'0' => array('val' => 10, 'text' => 'mon texte 10'),
'1' => array('val' => 1, 'text' => 'mon texte 1'),
'2' => array('val' => 3, 'text' => 'mon texte 3'),
'3' => array('val' => -2, 'text' => 'mon texte -2'),
'4' => array('val' => 8, 'text' => 'mon texte 8'),
'5' => array('val' => 50, 'text' => 'mon texte 50'),
'6' => array('val' => 5, 'text' => 'mon texte 5'),
);

Nous allons donc utiliser la fonction usort qui permet de trier un tableau suivant une fonction que l’on définit. Nous allons donc créer une fonction comparant les clés.

	function fonctionComparaison($a, $b){
		return $a['val'] > $b['val'];
	}

Puis nous l’appelons de la manière suivante :

usort($a, 'fonctionComparaison');

Pour la même utilisation au sein d’une classe (si « fonctionComparaison » était une des méthodes de la classe), le second paramètre est alors un tableau :

usort($a, array($this,'fonctionComparaison'));

Et voici le résultat :

A noter que les clés originales ont été remplacées par de nouvelles. Pour conserver les clés, il aurait fallu utiliser la fonction uasort qui fonctionne exactement de la même manière, mais qui conserve les clés.

Photo

Il est en effet important de divulguer le moins d’informations possible à un éventuel pirate, en effet ce dernier pourrait se servir de ces informations pour mieux cibler son attaque.

Pour ce faire nous allons utiliser les directives Apache ServerSignature et ServerTokens.

La première directive que nous allons modifier est ServerSignature, qui par défaut (On) affiche sur chacune des pages d’erreur générée les informations concernant le serveur.

Une fois la directive ServerSignature à Off, le serveur n’affiche plus aucune information sur les pages d’erreur.

La seconde directive est ServerTokens permet de modifier le contenu du champ « Server » qui se situe dans l’entête de chaque réponse envoyée par le serveur. Nous pouvons voir très simplement cette réponse grâce à la commande Telnet. Nous voyons ici qu’il s’agit d’un serveur Apache en version 2.2.15 installé sur une CentOS.

Une fois la directive ServerTokens à Prod (Pour Product Only), le champ « Server » contiendra uniquement le nom du serveur web utilisé.

Pour modifier ces deux directives, il suffit d’éditer le fichier httpd.conf

vi /etc/httpd/conf/httpd.conf

De rechercher les lignes contenant ServerSignature et ServerTokens pour les remplacer par

ServerSignature Off

Et

ServerTokens Prod

Pour valider le changement de configuration, il suffit de recharger la configuration d’Apache

service httpd reload

Photo

Une remarque avant de commencer, selon votre version d’Apache les chemins vers les différents fichiers/dossiers peuvent changer. Cette documentation a été écrite avec Apache2.2.21.

Les premières étapes sont des commandes DOS, la première chose est donc d’ouvrir une invite de commande (Démarrer -> Exécuter -> cmd -> OK)

1 – Se rendre dans le répertoire de d’apache

cd C:\wamp\bin\apache\Apache2.2.21\bin

2 – Générer le la clef privé

On va commencer par générer la clé privée, elle se trouvera dans le fichier « private.key » ici le chiffrage est de 2048bits.

openssl genrsa -aes256 -out private.key 2048

Si vous rencontrez l’erreur « L’ordinal 296 …. SSLEAY32.dll » :

La solution est de se rendre sur cette page : http://slproweb.com/products/Win32OpenSSL.html et de télécharger Win32 OpenSSL v1.0.0k Light une fois installé il faut se déplacer dans le répertoire/sous-répertoires d’installation afin de copier les fichiers suivants :

• ssleay32.dll
• libeay32.dll
• openssl.exe

Pour les coller dans le dossier C:\wamp\bin\apache\Apache2.2.21\bin (en confirmant les remplacements). Le problème devrait alors être corrigé et la commande précédente s’exécuter correctement.

3 – Supprimer la passphrase

On va libérer la clé privée de la « passphrase » qui la protège.

openssl rsa -in private.key -out private.key

4 – Générer le certificat auto-signé

Nous allons ici générer le certificat auto-signé qui servira à certifier la connexion et à en chiffrer les échanges.

Ici le certificat sera valide 100 ans, remplacez donc 36500 par le nombre de jours de validité du certificat. Ensuite l’invite de commande vous demandera quelques informations libres à vous de les saisir. Notre certificat portera le nom : « certificat.crt »

openssl req -new -x509 -nodes -sha1 -key private.key
-out certificat.crt -days 36500
-config C:\wamp\bin\apache\apache2.2.21\conf\openssl.cnf

5 – Copier le certificat et la clef privée

Maintenant que notre certificat et notre clef privée sont générés il nous faut les stocker sur le serveur. Pour ce faire rendez-vous dans le dossier C:\wamp\bin\apache\Apache2.2.21\conf et créez deux dossiers « cert » et « key ».

• Copier certificat.crt dans le dossier « cert »
• Copier private.key dans le dossier « key »

6 – Édition des fichiers de configurations

Afin d’installer notre certificat, nous devons éditer trois fichiers de configuration, les deux premiers permettrons d’activer SSL pour Apache et PHP et le troisième permettra d’installer le certificat sur le serveur.

• Editer C:\wamp\bin\apache\Apache2.2.21\conf\httpd.conf

Dé-commenter les lignes (enlever le « # ») suivantes :

LoadModule ssl_module modules/mod_ssl.so

et

Include conf/extra/httpd-ssl.conf

• Editer C:\wamp\bin\php\php5.3.8\php.ini

Dé-commenter la ligne (enlever le « ; ») suivante

extension=php_openssl.dll

• Editer C:\wamp\bin\apache\Apache2.2.21\conf\extra\httpd-ssl.conf

Rechercher la ligne : <VirtualHost _default_:443>

Sous cette ligne, effectuer les recherche/remplacement suivant :

• Remplacer la ligne « DocumentRoot … » par :

DocumentRoot "c:/wamp/www/"

• Remplacer la ligne « ServerName … » par :

ServerName localhost:443

• Remplacer la ligne « ErrorLog … » par :

ErrorLog "c:/wamp/bin/apache/Apache2.2.21/logs/ssl_error.log"

• Remplacer la ligne « TransferLog … » par :

TransferLog "c:/wamp/bin/apache/Apache2.2.21/logs/ssl_access.log"

• Remplacer la ligne « SSLCertificateFile … » par :

SSLCertificateFile "c:/wamp/bin/apache/Apache2.2.21/conf/cert/certificat.crt"

• Remplacer la ligne « SSLCertificateKeyFile … » par :

SSLCertificateKeyFile "c:/wamp/bin/apache/Apache2.2.21/conf/key/private.key"

• Remplacer la ligne « <Directory …> » par :

<Directory "c:/wamp/www/">

• Remplacer la ligne « CustomLog … » par :

CustomLog "C:/wamp/bin/apache/Apache2.2.21/logs/ssl_request.log" \

Voici quelques explication concernant les paramètres que l’on viens de modifier :

• DocumentRoot : définit le dossier racine du serveur
• ServerName : définit le nom du serveur et son port d’écoute (443 étant le port SSL par défaut)
• ErrorLog : définit l’emplacement du journal d’erreur
• TransferLog : définit l’emplacement du journal des accès
• SSLCertificateFile : définit l’emplacement du certificat
• SSLCertificateKeyFile : définit l’emplacement de la clef privée
• <Directory …> : définit les propriétés sur dossier racine
• CustomLog : définit l’emplacement du journal des requêtes

7 – Vérifier la configuration

Dans une invite de commande tapez la commande suivante

httpd -t

Ce dernier doit retourner « Syntax OK », si tel n’est pas le cas, il doit y avoir une erreur dans le fichier « httpd-ssl.conf », il faut donc retourner à l’étape précédente et vérifier la configuration.

8 – Redémarrer Wamp

Il faut redémarrer Wamp afin que les différentes modifications soient prises en compte.

9 – L’accès à https://localhost/ doit être possible

Le message suivant nous indique que la connexion n’est pas certifiée, il faut accepter les risques, c’est normal puisque notre certificat est auto-signé. Cette erreur n’apparaîtrait pas si le certificat aurait été acheté auprès d’une autorité de certification.

Voilà, le certificat est installé avec succès.

La mise en place d’Ambiance est très simple il suffit d’inclure jQuery ainsi que le plugin

<script type="text/javascript" src="/js/jquery-1.9.1.js"></script>
<link href="/css/jquery.ambiance.css" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="/js/jquery.ambiance.js"></script>

Pour l’initialisation et l’affichage des notifications, c’est très simple, la seule information obligatoire est le message à afficher :

$.ambiance({message: "Texte à afficher à l'utilisateur."});

Pour déterminer le temps d’affichage de la notification il suffit d’utiliser le paramètre timeout, qui définit la durée d’affichage en secondes

$.ambiance({message: "Cette notification sera affichée 10 secondes.", "<code>timeout</code>" : 10});

Dernier point intéressant, la personnalisation des notifications, pour cela, il faudra utiliser le paramètre type, le plugin possède trois types à savoir :

• default : Notification noire
• success : Notification verte
• error : Notification rouge

$.ambiance({message: "Action réalisée avec succès.", "type": "success", "<code>timeout</code>" : 10});

Il est aussi possible de créer des types personnalisés en créant des classes CSS ayant comme nom « ambiance-nom_du_type », il est aussi possible de changer complètement l’apparence du plugin en éditant ou surchargeant les propriétés CSS.

Site officiel

Après plusieurs vérifications de la configuration de phpMyAdmin, l’analyse des logs Apache nous informe d’une erreur lors de l’accès :

[notice] child pid XXXX exit signal Segmentation fault (11)

Le problème viens d’eAccelerator, un module de PHP permettant d’accélérer l’exécution des scripts. Pour corriger le problème, il suffit de désactiver eAccelerator. Pour ce fait, il faut éditer le fichier eaccelerator.ini

vi /etc/php.d/eaccelerator.ini

Et commenter la ligne suivante (en ajoutant un dièse devant) :

#avant
extension="eaccelerator.so"
#après
#extension="eaccelerator.so"

Et pour finir, il ne faut pas oublier de redémarrer Apache :

service httpd restart

Sommaire du tutoriel

1. Effectuer des tests de montée en charge avec Tsung (Partie 1 – Installation)
2. Effectuer des tests de montée en charge avec Tsung (Partie 2 – Configuration)
3. Effectuer des tests de montée en charge avec Tsung (Partie 3 – Le test)

1 – Lancer le test

Nous pouvons ensuite lancer le test avec la commande (qui par défaut chargera le fichier de configuration ~/.tsung/tsung.xml) :

tsung start

Pour utiliser un autre fichier de configuration, il faut passer le chemin de ce dernier à la commande, soit :

tsung -f ~/.tsung/tsung-second-test.xml start

Au lancement du test, Tsung crée un dossier contenant les logs, que nous utiliserons plus tard pour générer le rapport.

La montée en charge est maintenant lancée vous pouvez à tout moment l’arrêter en tapant la commande « Tsung stop » ou la combinaison de touche ctrl+c

2 – Générer le rapport

Une fois le test terminé, il faut se rendre dans le dossier contenant les logs :

Cd ~/.tsung/log/20130201-2348

Et ensuite générer le rapport avec la commande (notez qu’il sera plus pratique de créer un alias nommé par exemple « tsung-repport » que d’exécuter cette commande).

/usr/lib/tsung/bin/tsung_stats.pl

Le rapport se trouvera alors dans le même dossier que les logs, et se nommera « repport.html »

L’ouverture du rapport peut se faire entre autre avec la commande (A condition d’utiliser l’option –X de ssh)

firefox report.html

Le rapport possède deux parties, la première étant composée de statistiques,

et la seconde de graphiques.

Il ne reste maintenant plus qu’à analyser le rapport afin de tirer les conclusions de cette montée en charge. A noter que le rapport ci-dessus a été généré en quelques secondes de tests (d’où le peu d’informations qu’il contient).

Sommaire du tutoriel

1. Effectuer des tests de montée en charge avec Tsung (Partie 1 – Installation)
2. Effectuer des tests de montée en charge avec Tsung (Partie 2 – Configuration)
3. Effectuer des tests de montée en charge avec Tsung (Partie 3 – Le test)

1 – Copier un exemple basique dans ~/.tsung

Tsung propose plusieurs fichiers d’exemples de configuration, et nous allons ici en prendre un simple afin de l’adapter à notre application. Il faut tout d’abord vérifier l’existence du répertoire ~/.tsung qui est l’emplacement des fichiers de configuration et de journaux de Tsung.

Mkdir ~/.tsung

Copier ensuite le fichier d’exemple.

cp  /usr/share/doc/tsung/examples/http_simple.xml ~/.tsung/tsung.xml

2 – Enregistrement d’un scénario

A cette étape nous allons utiliser la commande « Tsung-recorder » pour enregistrer un scénario de navigation, c’est-à-dire l’activité d’un internaute sur notre application. Cette étape est néanmoins optionnelle puisqu’il sera possible d’écrire notre scénario directement dans le fichier de configuration de Tsung (un scénario peut être juste le chargement d’une page, un fichier etc.).

Pour lancer l’enregistrement d’un scénario il suffit de taper la commande :

tsung-recorder start

Tsung-recorder lancera un proxy qui écoutera sur le port 8090 et enregistrera la navigation dans un fichier. Il suffira ensuite de paramétrer un navigateur internet afin qu’il utilise ce proxy.

Tsung recorder nous indiquera aussi le nom du fichier généré.

L’étape suivante est de lancer le navigateur (ici Firefox) installé sur le serveur. Si vous ne possédez pas d’interface graphique sur le serveur, il faudra rediriger la sortie graphique avec l’option –X de ssh.

Pour ce faire, il faut tout d’abord installer les paquets X Window.

yum groupinstall 'X Window System'

Ouvrir une nouvelle session SSH.

ssh –X utilisateur@serveur

Puis lancer Firefox via la commande.

Firefox

Votre navigateur doit alors s’ouvrir. Il suffit maintenant de configurer le proxy et de naviguer sur l’application que l’on souhaite tester.

Une fois terminé, taper la commande suivante pour arrêter l’enregistrement :

tsung-recorder stop

Nous pouvons visualiser l’enregistrement en ouvrant le fichier :

cat  ~/.tsung/tsung_recorder20130201-2335.xml

Voici un extrait du contenu :

<request><http url='/index.html' version='1.1' method='GET'></http></request>
<request><http url='/contact.html' version='1.1' method='GET'></http></request>

3 – Configuration du test

Maintenant que tout est installé et que notre scénario est enregistré, nous allons éditer la configuration de notre test afin de renseigner tous les paramètres de la montée en charge. Pour cela il faut éditer le fichier tsung.xml

Dans le XML de configuration, quatre nœuds vont nous intéresser :

• <Clients> : Il s’agit de définir les clients utilisés par Tsung. Il est possible de définir les IP, nombre d’utilisateurs maximum, nombre de processeurs etc.
• <Servers> : Défini le serveur cible (notre plateforme à tester).
• <Load> : Défini la/les phase(s) d’arrivée(s) de nos visiteurs, c’est-à-dire les étapes de notre montée en charge. Le nœud Load est donc composé d’un ou plusieurs nœuds arrivalphase.
  • <Arrivalphase> : Contient les détails d’une phase d’arrivée : durée, nombre d’utilisateurs à simuler, fréquence d’arrivée des visiteurs …
  • Généralement, plusieurs phases seront définies en accentuant la montée en charge, jusqu’à arriver à un stress intensif.
• <Sessions> : Contient les scénarios d’utilisation possible. Chaque scénario équivaut à un nœud « Session », et est composé de « Request ». A noter qu’il est possible de définir des probabilités pour les scénarios (le total des probabilités doit toujours être égal à 100).
  • Les boucles : permettent d’augmenter le nombre de requêtes à effectuer sur l’application. Tsung nous permet de boucler sur les balises <request>, via l’utilisation de <For> …
  • <for from= »1″ to= »10″ var= »i »><request>…</request></for> : Pour boucler 10 fois sur les <Request>, de façon à générer encore plus de requêtes sur notre plateforme.

Maintenant que nous avons présenté rapidement les principaux points du fichier de configuration, nous allons passer à l’édition. Pour ce faire, il suffit d’ouvrir le fichier ~/.tsung/tsung.xml, et de le modifier afin de créer la configuration de test idéale pour votre architecture, vos besoins, etc.

vi ~/.tsung/tsung.xml

Voici un exemple de fichier XML :

<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">

	<!-- Configuration du client -->
	<clients>
		<client host="localhost" use_controller_vm="true"/>
	</clients>

	<!-- Configuration du serveur -->
	<servers>
		<server host="192.168.1.11" port="80" type="tcp"></server>
	</servers>

	<!-- phases d'arrivée, 3 paliers de 10 minutes où l'on augmente la fréquence d'arrivée de 1 puis 10 puis 30 visiteurs par seconde -->
    <load>
        <arrivalphase phase="1" duration="10" unit="minute">
            <users arrivalrate="1" unit="second"></users>
        </arrivalphase>
        <arrivalphase phase="2" duration="10" unit="minute">
            <users arrivalrate="10" unit="second"></users>
        </arrivalphase>
        <arrivalphase phase="3" duration="10" unit="minute">
            <users arrivalrate="30" unit="second"></users>
        </arrivalphase>
    </load>

	<!-- Les scénarios -->
	<sessions>
		<!-- Scénarios 1 avec 70% de probabilité, l'internaute charge successivement 3 pages -->
		<session name="scenario1" probability="70" type="ts_http">
			<request><http url='/page1.html' version='1.1' method='GET'></http></request>
			<request><http url='/page2.html' version='1.1' method='GET'></http></request>
			<request><http url='/page3.html' version='1.1' method='GET'></http></request>
		</session>
		<!-- Scénarios 2 avec 30% de probabilité, l'internaute charge 10 fois la page 1 -->
		<session name="scenario2" probability="30" type="ts_http">
			<for from="1" to="10" var="i">
				<request><http url='/page1.html' version='1.1' method='GET'></http></request>
			</for>
		</session>
	</sessions>
</tsung>

Dans la troisième et dernière partie de ce tutoriel nous verrons comment lancer le test de montée en charge et générer un rapport.

Tsung est un outil permettant d’effectuer des tests de montée en charge sur une architecture. Une de ses particularités, est qu’il ne se limite pas au protocole HTTP, mais gère aussi WebDAV, SOAP, PostgreSQL, MySQL ou encore LDAP. Tsung est gratuit, distribué sous licence GPLv2 et dispose d’une documentation relativement claire.

Le principe est relativement simple : l’application va simuler l’arrivée de nombreux utilisateurs sur la plateforme. Le plus de Tsung par rapport à ses concurrent est de pouvoir créer des scénarios d’utilisation (et propose même un utilitaire d’enregistrement de scénario). Cela signifie que l’application ne se contente pas de charger une page à intervalle régulier, mais de simuler la navigation sur la plateforme.

Une fois le test terminé, Tsung nous permettra de générer un rapport contenant une série de graphiques ; l’analyse sera donc relativement simple.

L’utilisation d’utilitaires de montée en charge comme Tsung permet :

• De connaître la charge qu’une plateforme peut supporter
• Vérifier que la capacité d’accueil de la plateforme est conforme aux spécifications (et donc aux demandes d’un client par exemple)

Avant d’utiliser cet outil, il est bon de s’assurer de deux choses :

• Que le réseau est suffisamment dimensionné : en effet un réseau sous dimensionné créera un goulot d’étranglement en amont de notre plateforme.
• La plateforme doit vous appartenir. Dans le cas contraire, vous devez avoir un accord de l’hébergeur.

Nous allons ici nous intéresser à la mise en place d’un test simple sur une application web. Nous effectuerons les manipulations sous CentOS, les commandes seront donc identiques sous Fedora et Red Hat (RHEL). Pour les autres distributions, seuls les noms des paquets devraient changer ainsi que deux ou trois commandes.

Sommaire du tutoriel

1. Effectuer des tests de montée en charge avec Tsung (Partie 1 – Installation)
2. Effectuer des tests de montée en charge avec Tsung (Partie 2 – Configuration)
3. Effectuer des tests de montée en charge avec Tsung (Partie 3 – Le test)

1 – Installer CentOS

Comme dit précédemment, nous utiliserons CentOS, la version 6.3 minimale. Pour le téléchargement, c’est par ici.

La première étape sera donc l’installation de la distribution.

2 – Ajouter les dépôts additionnels

Nous installons ici les dépôts RPMForge, EPEL et Remi qui nous servirons à installer les paquets requis pour l’installation de Tsung.

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*
rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

rpm -ivh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

3 – Mise à jour de la distribution et installation des paquets utiles

Nous allons maintenant mettre à jour la distribution et installer les paquets Man, Locate, Bash-Completion, Make et Wget.

yum update
yum install man mlocate bash-completion make wget

4 – Installer les pré-requis

Nous allons maintenant installer les paquets requis pour l’installation de Tsung. Il s’agit d’Erlang, Perl, Gnuplot ainsi que certains modules de Perl.

yum install erlang perl gnuplot perl-RRD-Simple.noarch perl-Log-Log4perl-RRDs.noarch perl-Template-Toolkit

Nous installerons aussi Firefox car il nous servira pour la visualisation des rapports.

yum --enablerepo=remi install Firefox

5 – Installation de Tsung

Nous allons maintenant passer à l’installation de Tsung à proprement parler. A l’heure de l’écriture de ce guide, Tsung est en version 1.4.2. La dernière version se trouve sur le site officiel.

Pour le téléchargement :

cd /tmp
wget http://tsung.erlang-projects.org/dist/tsung-1.4.2.tar.gz

Ensuite il faut décompresser l’archive et compiler Tsung. Cette dernière opération peut être un peu longue.

tar zxfv  tsung-1.4.2.tar.gz
cd tsung-1.4.2
./configure && make && make install

Partie 2 : La configuration de Tsung

Forcer l’utilisation des www permet en plus de faire plus esthétique ou plus professionnel d’éviter le « duplicate content » (duplication de contenu) lors de votre référencement. Ainsi toutes vos pages seront référencées avec le www dans le nom de domaine.

Pour ce faire il suffit d’ajouter les lignes suivantes en haut de votre fichier .htaccess

RewriteEngine On
RewriteCond %{HTTP_HOST} ^mon-site.com [NC]
RewriteRule ^(.*)$ http://www.mon-site.com/$1 [L,R=301]

Ainsi, les personnes accédant à http://mon-site.com seront automatiquement redirigées vers http://www.mon-site.com

A noter que si vous utilisez déjà la réécriture d’URL est déjà activée sur votre site, il sera alors inutile d’ajouter la première ligne.