URL Rewriting et WebDev

[lolob84]

Bonjour,

L'objectif de cette discussion est de vous présenter différentes approches de l'URL Rewriting avec WebDev. Ces approches seront dépendantes et de la version de WebDev, et/ou du serveur Web utilisé 'Apache, IIS, etc...). Les solution s proposées sont loin d'être exhaustives et sans défaut, mais peuvent répondre à différents besoins et contraintes de déploiement (Serveur Web mutualisé, dédié, ...).

Les solutions propres à WebDev.

1. URL Courte

La solution la plus simple et également la plus limitée, puisqu'elle ne propose que la possibilité de gérer une URL courte sur des pages dynamiques classiques WebDev.

Vous connaissez tous l'habituel lien d'un site dynamique

Code :

http://www.monsite.com/WD160AWP/WD160AWP.EXE/CONNECT/MonSiteWeb

Votre adresse pourra devenir, sans passer par une page html de redirection :

Code :

http://monsite.com/MonSiteWeb

L'apport est limité mais indéniable. Plus besoin de créer une page index manuel avec une redirection dedans.

Limites et contraintes : WebDev 16 minimum, IIS 7 ou +, Apache 1.3, 2.2

2. L'URL Rewriting WebDev.

Reprenons l'exemple de l'aide en ligne, sachant qu'il est faux pour la plupart des déploiements :

Code :

http://www.monsite.com/PAGE_FicheProduit.awp?Categorie=Voitures&Marque=Ferrari&Millesime=2008

En fait, l'adresse sera plutôt ça :

Code :

http://www.monsite.com/MonSiteWeb_WEB/FR/PAGE_FicheProduit.awp?Categorie=Voitures&Marque=Ferrari&Millesime=2008

Avec le rewriting WebDev on peut obtenir ça:

Code :

1
2
3
http://www.monsite.com/voiture-ferrari-2008.awp
ou bien :
http://www.monsite.com/ferrari/2008/voitures.awp

ou plutôt, en étant réaliste :

Code :

1
2
3
4
http://www.monsite.com/MonSiteWeb_WEB/FR/voiture-ferrari-2008.awp
ou bien :
http://www.monsite.com/MonSiteWeb_WEB/FR/ferrari/2008/voitures.awp

On se rapproche d'une simplification correcte des pages. Vous pouvez vraiment régler les règles de réécriture des pages. Je vous laisse consulter l'aide en ligne qui est très claire la dessus :
http://doc.pcsoft.fr/fr-FR/?2030054&name=URL_Rewriting

Limites et contraintes : WebDev 15 minimum, IIS 5 ou +, Apache 1.3, 2.2 - ATTENTION : Ne fonctionne pas sous Apache 2.0

Une solution externe : IIRF

Cette solution est une solution permettant d'appliquer un principe d'url rewriting quasi identique au système Apache.
D'autres solutions existent bien sur, mais celle ci à l'avantage d'être gratuite, très complète et légère.
Comme la plupart des autres solutions sous IIS, IIRF fonctionne comme un filtre ISAPI . D'ailleurs, son nom complet est très clair : Ionics Isapi Rewrite Filter

Vous pouvez le télécharger et trouver toutes les infos utiles ici :
http://iirf.codeplex.com/

L'installation est très simple et bien documentée dans l'aide. Je n'ai pas rencontré de difficultés dans la mise en oeuvre.
Pour activer IIRF sur un site Web, il faut l'ajouter aux filtres ISAPI du site web voulu. Ajouter un nouveau filtre et donnez lui un nom clair (IIRF ou URL Rewrite) et pour l’exécutable, allez pointer sur la DLL IIRF.dll qui se trouve dans le répertoire bin de votre installation IIRF.

Désolé de ne pas être plus clair, mais entre les différentes versions de IIS, la procédure et les écrans pour ajouter un filtre ISAPI sur un site peuvent être très différentes, même si elles restent très simple. Référez vous à l'aide de IIS sur l'ajout de filtre ISAPI.

Le paramétrage du rewriting se fait ensuite par fichiers INI, placés dans les répertoires du site qui utiliseront des règles de rewriting.
Cela ressemble énormément au fonctionnement des .htaccess des serveurs Apache.

Vous créez un fichier appelé IIRF.ini par répertoire du site dans lequel on veut gérer l'URL rewriting.
Sur un site WebDev, cela va nous intéresser sur le répertoire racine, par exemple pour éviter de gérer une page de redirection, dans le répertoire MonSiteWeb_WEB/FR et/ou les autres langues.

Ensuite chaque fichier INI va remplir son role. Un exemple :
Le fichier INI du répertoire racine :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
# Regles de réécriture pour MonSiteWeb.com
# Fichier de paramétrage pour la racine du site
#
# Ce fichier DOIT être placé dans le répertoire racine (NOMDUSITE)
#
#    Date de MAJ : 8/11/2010

RewriteLogLevel    1
RewriteLog     c:\inetpub\iirfLogs\iirf   
RewriteEngine     ON
StatusInquiry     ON
RewriteBase     ON
#IterationLimit    5

Redirection pages awp - Penser à rediriger ici toutes les pages déclarées dans le répertoire AWP pour avoir un lien court.

Code :

1
2
RedirectRule ^/MonTest-(.*)$  /MonSiteWeb_WEB/FR/MonTest-$1             [I]

Ici, un exemple de redirection vers le répertoire FR du site, et dans ce répertoire, on aura une réécriture d'adresse.
Ex : http://www.monsite.com/MonTest-1 renvoie vers http://www.monsite.com/MonSiteWeb_Web/FR/MonTest-1

Redirection vers un répertoire contenant par exemple des documents rangés dans un sous répertoire spécifique (ici 2 parametres :le nom du client, puis le document)

Code :

1
2
RedirectRule ^/VoirDocument/(.+)-(.+)$ /DonnéesClient/$1/Documents/$2        [I]

ex : http://www.monsite.com/VoirDocument/...nTel-Tarif.pdf renvoie vers http://www.monsite.com/MonSiteWeb_Web/DonnéesClient/ClientUntel/Tarif.pdf

Transformer une adresse dynamique

Code :

1
2
RewriteRule ^/Entreprise-(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]

Ex : http://www.monsite.com/Entreprise-ClientUnTel devient
http://www.monsite.com//WD150AWP/WD1...se=ClientUnTel
Liens anciennes versions... Si votre site a de nombreuses années et a diffusé des liens sous d'anciennes versions, vous êtes couvert!

Code :

1
2
3
4
5
RewriteRule ^/WD140AWP/WD140AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
RewriteRule ^/WD120AWP/WD120AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
RewriteRule ^/WD110AWP/WD110AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]
RewriteRule ^/WD100AWP/WD100AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=(.+)$ /WD150AWP/WD150AWP.EXE/CONNECT/MonSiteWeb?ParamMode=1&ParamIDEntreprise=$1 [L,I]

Ensuite, pour être cohérent dans mon exemple, le fichier IIRF.ini placé dans le répertoire FR en lien avec les instructions passées dans le fichier ini du répertoire racine.

IIRF.ini

Code :

1
2
3
4
5
6
7
8
9
10
11
12
# Règles de réécriture 
RewriteLogLevel 1
RewriteLog     c:\inetpub\iirfLogs\iirf
RewriteEngine     ON
StatusInquiry     ON
RewriteBase     ON
#IterationLimit    5

#Réécriture des adresses...

#Adresses de consultation de profil
RewriteRule ^/MonTest-(.*)$ /Consulter_Profil.awp?p1=$1         [L,I]

Cette réécriture appelle la page awp Consulter_Profil.awp. ce qui donnerai sous forme d'URL :
http://www.monsite.com/MonTest-1 <==> http://www.monsite.com/MonSiteWeb_We...rofil.awp?p1=1

Pas mal, non?

Voilà , il y a beaucoup d'autres possibilités dans IIRF, je vous laisse le soin de consulter les fichiers d'exemples et la documentation. Il existe également d'autres solutions qui fonctionnent très bien. Il est clair que IIRF ne peut être mis en oeuvre que sur vos serveurs ou serveurs dédiés. Certains hébergeurs comme Kalanda proposent une solution qu'ils intègrent dans leurs serveurs mutualisés et qui ressemble beaucoup à cette solution dans la mise en oeuvre (même principe que le .htaccess d'Apache.)


Limites et contraintes : IIS 5 ou +(pas testé en dessous), Serveur dédié ou hébergeur mutualisé acceptant l'ajout de scripts ou programmes.

Je vous laisse libre d'apporter vos commentaires et autres solutions sur cette contribution qui, comme je le disais au départ, est loin d'être exhaustive et ne demande qu'à être enrichie.

Cordialement,

Laurent B.

[nonoxp]

Bonjour,

Je rebondis sur la solution IIRF que je viens d'implémenter.
C'est assez simple du moment qu'on suit le tuto d'install et de config à la lettre, par contre je conseille de valider toutes les étapes comme indiqué dans le configuration manuelle.

Le contexte et le problème :
On a des pages applicatives situées dans un sous-site d'un site Sharepoint 2007, tournant sur un IIS6. Ceci crée une arborescence assez disgracieuse.
Contrairement à un site pur IIS, il n'est pas possible de créer un site de type "racine" si l'arborescence n'est pas en filesystem. C'est un inconvénient de Sharepoint, heureusement on a la solution de la réécriture (un reverse proxy aurait pu faire l'affaire également).

Le cas d'utilisation de ma réécriture est le suivant :
Des utilisateurs mobiles au sein de l'entreprise souhaitent accéder rapidement à ces pages. Des utilisateurs itinérants se connectent via leur mobile au travers d'une passerelle qui, pour simplifier ses règles de filtrage, requiert une url simple. Pour cela, je crée une entrée dns (interne) pointant vers mon serveur IIS.

En gros, on va faire un genre d'obfuscation du nom d'hôte + arborescence pour faire croire à la passerelle qu'on a un site de type racine.

Exemple :

Code :

1
2
3
4
navigateur utilisateur : 
http://monsitemobi.domaine/ , 
page exécutée en réalité :
http://serveursharepoint.domaine/sites/monsoussite/mobi/default.aspx

Peut de conditions/règles suffisent à implémenter ceci. Il y a encore des cas que je dois tester, mais grosso modo ça donne :

Code :

1
2
3
4
RewriteEngine ON
RewriteCond %{HTTP_HOST} ^monsitemobi\.domaine$
RewriteRule ^[\/](\?){0,1}$  	    /default.aspx
RewriteRule (.*)$   /sites/monsoussite/mobi$0   [L]

L'intérêt principal de la solution : le filtre ISAPI iirf se lance avant celui d'asp.net. Ainsi, nous ne sommes pas limités dans nos redirections (plusieurs solutions existantes dépendent du filtre isapi asp, limitant le type de pages interceptées).

Autres avantages :
- pas de redémarrage du serveur,
- les règles sont rechargées en fonction de la date de dernière modification du fichier ini,
- niveaux de log acceptables (paramétrables) pour un environnement de prod,
- les erreurs sont administrables (event viewer) dans le cas où les logs ne suffisent pas,
- un module de test de vos redirections sous la forme d'un exécutable console permet de valider vos redirections.

Pour peu que les urls internes de vos pages/liens/ressources soient rédigées avec un path relatif au root, vous n'avez rien à changer.