URL Rewriting - Les variables


Lors de la réécriture de nos différentes URLs, nous allons utiliser des conditions et le plus souvent, des variables du serveur, l'entête HTTP ou même l'horodatage !

Il existe énormément de variables que l'on peut tester, certaines donnent d'excellentes informations (comme l'agent du navigateur du visiteur), d'autres sont moins souvent utiles mais il convient de savoir utiliser !

Certaines de ces variables correspondent aux en-têtes MIME HTTP (Multipurpose Internet Mail Extensions), d'autres à des variables C du serveur Apache ou au système Unix.

Les variables « spéciales » sont uniquement utilisées et disponibles pour l'URL Rewriting.

Ce tutoriel vient en appui du de l'URL Rewriting dont nous parlons ici : Tutoriel sur l'URL Rewriting. Si vous ne connaissez encore rien sur l'URL Rewriting, nous vous conseillons de commencer par ce tutoriel. Vous reviendrez ici par la suite lorsque vous en aurez besoin.

Suivez le guide !

Les variables à l'intérieur de l'URL Rewriting


Dans cette sous-partie, nous allons regarder une à une comment se servir de chaque variable d'URL Rewriting. Vous pouvez cliquer sur l'une d'entre elle dans le tableau ci-dessous pour accéder directement à sa définition.

Notez que toutes les variables décrites ici s'utilisent avec une règle « RewriteCond » ou « RewriteRule » . Quelques exemplee sont disponibles pour vous aider.


Suivez le guide ! En-tête HTTP

Variable Description
HTTP_USER_AGENT

Retourne une chaîne de caractères décrivant le navigateur qui envoie la requête. On obtient la même chose que la variable : « REMOTE_HOST ».

Par exemple, pour la navigateur Firefox, nous aurons : « Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ».

HTTP_REFERER

Retourne l'URL de la page précédente, celle qui à conduit à la page actuelle. Utile pour connaitre les sites qui ont des liens sur le vôtre et l'origine des erreurs 404 par exemple.

Exemple : http://www.craym.eu/tutoriels/url_rewriting.html

HTTP_FORWARDED

Retourne l'IP exacte du client qu'il a utilisé pour se connecter au serveur (même si utilisation de proxy).

Note : En utilisant « REMOTE_ADDR », vous pouvez comparer les IPs et détecter l'utilisation d'un proxy.

HTTP_HOST

Retourne le nom du serveur qui a été demandé dans la requête.

Exemple : localhost ou craym.eu

HTTP_PROXY_CONNECTION

Retourne le Timeout statu de la connexion HTTP proxy. Généralement, cette valeur est « keep-alive ».

HTTP_ACCEPT

Retourne la valeur de l'entête « Accept ». Ces valeurs sont des standards MIME-types.

Exemple : HTTP_ACCEPT: text/html



Suivez le guide ! Connexion et requête


Variable Description
REMOTE_ADDR

Retourne l'IP du visiteur comme par exemple : 134.38.245.7.

REMOTE_HOST

Retourne le type de navigateur du visiteur. Par exemple, pour la navigateur Firefox, nous aurons :
« Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ».

REMOTE_PORT

Retourne le numéro du port utilisé par le client pour envoyer la requête.

REMOTE_USER

Retourne le nom d'utilisateur envoyé par le client.

Exemple : Bob

REMOTE_IDENT

Cette variable retourne des informations d'identités sur la requête envoyé par le client si celle-ci sont disponibles. Celles-ci étant modifiables, il est conseillé de ne pas les utiliser à des fin d'authentifications.

Exemple de valeur : =?UTF-8?b?0YHQsNGFNORDgA==?=

REQUEST_METHOD

Retourne la méthode utilisée pour créer la requête « GET », « HEAD » ou « POST ».

SCRIPT_FILENAME

Retourne le chemin complet local au système de fichiers du fichier ou du script correspondant à la requête si le chemin a déjà été déterminé par le serveur au moment où on y fait référence.

Dans le cas contraire, et en particulier dans le cas d'un serveur virtuel, « REQUEST_FILENAME » contient la valeur de « REQUEST_URI ».

Exemple, pour un serveur Unix, si l'utilisateur demande la page « index.html », le chemin retourné sera quelque chose comme : « home/user/public_html/index.html ».

PATH_INFO

Retourne le chemin virtuel (ou relatif) au système de fichiers. Il devra être interprété par le CGI avant d'obtenir le chemin complet local au système de fichiers.

Contrairement à l'URL, celui-ci ne peut pas contenir de paramètres.

QUERY_STRING

Retourne les paramètres passés par l'URL. Par exemple, si la requête concerne la page :
«
test.html?param1=a&param2=b » alors, la valeur de retour sera : « param1=a&param2=b ».

AUTH_TYPE

Retourne la méthode d'authentification que le serveur utilise pour valider les utilisateurs lorsqu'ils tentent d'accéder à un script protégé (souvent protégé avec un « .htpasswd »).

La valeur par défaut est : « basic »




Suivez le guide ! Variables internes au serveur


Variable Description
DOCUMENT_ROOT

Retourne le dossier racine du site web. C'est le dossier source ou l'on met les différents fichiers du site afin qu'ils soient visibles depuis le web.

Généralement, le dossier racine est « /www/» ou « /public_html/ » mais il peut parfois être
«
/web/public/ » ou encore « /example.com/www/public/ ».

Cette valeur dépend uniquement de la manière dont votre hébergeur gère les différents sites.

SERVER_ADMIN

Retourne le nom de l'administrateur du serveur ou plus généralement son adresse e-mail. Vous pouvez modifier cette valeur dans le fichier « httpd.conf ».

Exemple: webmaster@craym.eu

SERVER_NAME

Retourne le nom du serveur. Exemple : « mail.serveur1.com ».

SERVER_ADDR

Retourne l'adresse IP du serveur. Exemple : 134.212.98.67

SERVER_PORT

Retourne le numéro du port dont se sert le serveur pour traiter et répondre à la requête. Généralement, cette valeur est 80.

SERVER_PROTOCOL

Retourne la version du protocole utilisé par le serveur pour répondre à la requête CGI. Cette valeur peut être différente de la version du protocole utilisé par le serveur pour communiquer avec le client.

Exemple : HTTP /1.1

SERVER_SOFTWARE

Cette variable retourne le nom et la version du software qui exécute et traite la requête CGI. Elle est normalement la même que le nom du serveur retourné au client.

Exemple : Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch


Suivez le guide ! Date et heure

Variable Description
TIME_YEAR

Retourne l'année en cours. Exemple : 2010

TIME_MON

Retourne le mois en cours entre 01 et 12. Janvier correspond à 1 et Décembre à 12.

TIME_DAY

Retourne le N° du jour de 01 à 31 avec les zéro initiaux.

TIME_HOUR

Retourne l'heure sous sa forme double de 00 à 23 avec les zéro initiaux.

TIME_MIN

Retourne les minutes de 00 à 59 avec les zéro initiaux.

TIME_SEC

Retourne les secondes de 00 à 59 avec les zéro initiaux.

TIME_WDAY

Retourne le numéro du jour de la semaine : 1 (pour Lundi) à 7 (pour Dimanche)

TIME

Retourne le TIMESTAMP Unix de la date.

Un exemple d'utilisation des variables de temps :

1 2
3
4
5
6
RewriteEngine On

RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html
RewriteRule ^foo\.html$ foo.night.html

Dans cet exemple, on teste deux conditions: si l'heure est supérieure à 07h00 ET qu'elle est inférieure à 19h00, on réécrit l'URL de la page « foo.html » en foo.day.html.

Sinon, c'est la nuit et de 19h00 à 23h59, on affiche : « foo.night.html ».

Si l'on se trouve entre 00h00 et 06h59, alors on ne fait rien et on affiche : « foo.html »


Suivez le guide ! Variables spéciales

 

Variable Description
IS_SUBREQ

Variable qui contiendra la valeur booléenne « TRUE » si la requête en cours de traitement est une sous-requête, « FALSE » dans le cas contraire.

Une sous-requête est générée quand un module a besoin de se référer à des fichiers ou des URLs additionnels pour pouvoir mener à bien sa tâche.

1
2
3
RewriteEngine On
RewriteCond %{IS_SUBREQ} URL_en_traitement
RewriteRule (.+).html&page-([1-9]+) afficher_page.php?page=$2 [L]
API_VERSION

Une variable rarement utilisée. Il s'agit de la version de l'API des modules Apache, plus précisément de l'interface interne entre le serveur et les modules.

La version de l'API des modules correspond à la version d'Apache utilisée (pour Apache 1.3.14, par exemple, la version de l'API sera 19990320:10), mais cette information intéresse principalement les développeurs de modules.

THE_REQUEST

Retourne la ligne de requête HTTP complète qui a été envoyée par le navigateur au serveur.

Par exemple, si le visiteur a demandé la page « index.html », la requête complète du serveur sera « GET /index.html HTTP/1.1». Cela n'inclu pas les en-tête ajouté par le navigateur lui-même.

REQUEST_URI

Donne l'URI complète de la ressource demandée dans la ligne de requête HTTP.

Dans l'exemple précédent, cela correspondait à « /index.html ».

REQUEST_FILENAME

Retourne le chemin complet local au système de fichiers du fichier ou du script correspondant à la requête si le chemin a déjà été déterminé par le serveur au moment où on y fait référence.

Dans le cas contraire, et en particulier dans le cas d'un serveur virtuel, « REQUEST_FILENAME » contient la valeur de « REQUEST_URI ».

Exemple, pour un serveur Unix, si l'utilisateur demande la page « index.html », le chemin retourné sera quelque chose comme : « home/user/public_html/index.html ».

HTTPS

Contiendra le texte « on » si la connexion utilisée est de type SSL/TLS, « off » dans le cas contraire.

Notez que l'utilisation de cette variable est possible, indépendamment du fait que mod_ssl soit chargé ou non dans Apache.



Suivez le guide ! Quelques précisions

 

« SCRIPT_FILENAME » et « REQUEST_FILENAME »

Les variables « SCRIPT_FILENAME » et « REQUEST_FILENAME » ont la même valeur - celle du champ « filename » de la structure interne du serveur Apache « request_rec ».

Le premier nom est bien connu en tant que variable CGI (Common Gateway Interface, permet le lien entre le serveur et les requêtes HTTP), alors que le second est équivalent à « REQUEST_URI ».

Si une substitution survient, et si la réécriture se poursuit alors la valeur des deux variables est mise à jour en conséquence.

Dans un contexte de serveur principal (c'est-à-dire avant que la requête n'ait été mise en relation avec le système de fichiers), « SCRIPT_FILENAME » et « REQUEST_FILENAME » ne peuvent pas contenir le chemin local entier dans le système de fichiers, car celui-ci n'a pas encore été déterminé à ce stade du traitement.
Les deux variables contiennent alors la valeur de « REQUEST_URI ».

Pour obtenir le chemin local entier associé à la requête dans le système de fichiers toujours dans un contexte de serveur principal, utilisez une recherche immédiate : « %{LA-U:REQUEST_FILENAME} » pour déterminer la valeur finale de « REQUEST_FILENAME ». Cette syntaxe est expliquée plus bas.

Variante d'écriture

Il existe une petite variante dans l'URL à vérifier. On peut aussi utiliser %{ENV:variable}, où variable peut être remplacé par toute variable d'environnement décrite ci-dessus.

Ces variables sont d'abord recherchées dans les structures internes d'Apache via la fonction « getenv() » , et si elles n'y figurent pas, elles sont récupérées depuis le processus du serveur Apache.

Exemple :

1
2
3
RewriteEngine On
RewriteCond %{ENV:SERVER_ADDR} Condition
RewriteRule (.+).html&page-([1-9]+) afficher_page.php?page=$2 [L]

 

Variable SLL

Que le module « mod_ssl » d'Apache soit chargé ou non, on peut utiliser :

  • « %{SSL:variable} »

où « variable » peut être remplacé par le nom d'une variable d'environnement SSL.

Attention ! Si mod_ssl n'est pas chargé, la valeur produite sera toujours une chaîne de caractères vide .

Exemple :

1
2
3
RewriteCond %{SSL:SSL_CIPHER_USEKEYSIZE} Condition

# La variable SSL peut ici correspondre à 128


En-tête HTTP

Pour obtenir la valeur d'un en-tête contenu dans une requête HTTP, on peut toujours utiliser la syntaxe :

  • « %{HTTP:header} »

où « header » peut être remplacé par tout nom d'en-tête MIME HTTP.

1
2
3
RewriteCond %{HTTP:Proxy-Connection} Condition

# Ici, la valeur de la variable sera la valeur l'en-tête HTTP « Proxy-Connection »

Note : Si une condition contient un en-tête HTTP, alors il sera ajouté à l'en-tête Vary de la réponse si la condition est évaluée à « true » pour la requête. Dans le cas contraire, il n'est pas ajouté. L'ajout de l'en-tête HTTP à l'en-tête Vary de la réponse s'avère nécessaire pour une mise en cache correcte.

Gardez à l'esprit que les conditions sont évaluées dans l'ordre si bien que certaines ne seront peut-être jamais évaluées.

Sous-requêtes et contrôle

On peut utiliser la syntaxe :

  • « %{LA-U:variable} »

pour déterminer la valeur finale de « variable » , si la requête génère une sous-requête interne. Rapellez-vous que la chaine à tester est une première fois évaluée par le serveur afin de trouver sa valeur finale pour ensuite pouvoir effectuer la comparaison avec la chaine de condition.

Cette syntaxe peut donc servir à accéder à une variable (nécessaire pour une réécriture) qui n'est pas disponible dans la situation présente, mais le sera dans une étape ultérieure de la réécriture.

Par exemple, pour effectuer une réécriture qui tient compte de la variable « REMOTE_USER » grâce au fichier de configuration du serveur « fichier httpd.conf », vous devez utiliser « %{LA-U:REMOTE_USER} » car cette variable est définie au cours des phases d'autorisation, qui interviennent après la phase de traduction de l'URL.

En revanche, si on souhaite utiliser cette règle avec le fichier « .htaccess » qui lui à un contexte niveau répertoire, cela est possible car elle est disponible dès la traduction de l'URL. On peut donc obtenir l'accès à cette variable directement avec la syntaxe « %{REMOTE_USER} ».

On peut aussi utiliser la syntaxe :

  • « %{LA-F:variable} »

pour effectuer une sous-requête interne cette fois-ci basée sur un nom de fichier et non plus sur l'URL comme précédemment, pour déterminer la valeur finale de« variable ». La plupart du temps, elle sera identique à « %{LA-U:variable} » vue précédemment.

 

Vous pouvez maintenant retourner sur le tutoriel sur l'URL Rewriting ou lire un de nos autres tutoriels ici : Liste des tutoriels.

Félicitations ! Vous êtes arrivé à la fin de ce tutoriel ! Merci d'avoir pris le temps de nous lire !