I. Objet & principe :
La ré-écriture d’URL permet, en gros, d’afficher une page dont le nom n’est pas celui saisit par l’internaute ; quel interet à celà : utiliser par exemple 1 seule page jsp existant physiquement avec de multiples nom. Ceci peut avoir deux objetifs : donner un nom plus parlant à une page ou et c’est plus généralement le cas… aider fortement au référencement de son site web. Beaucoup de moteurs recherchent avant tout des mots clefs dans le titre et dans le nom de votre page. Ainsi, insérer des mots clefs dans l’URL est une bonne façon d’améliorer son référencement.
En général, l’URL rewriting se configure sur le serveur web (Apache) au travers de règles assez simple ; ce qui est une bonne solution, mais tout de même beaucoup moins drôle que de ré-écrire soit-même le mécanisme qui est globalement assez simple. Avantage d’utiliser une solution coté application : elle ne nécessite aucune config coté serveur en cas de crash/redeploiement, contexte dans lequel on retrouve toujours les sources mais jamais les fichiers de conf… croyez en mon expérience sur le sujet.
Sur le principe, c’est assez simple : les serveurs d’application on une page vers laquelle sont renvoyées les requêtes qui ne trouvent pas de destinataire (un catchAll en quelque sorte). C’est ici que nous allons agir, partant du principe que nos URL virtuelles n’existeront pas mais renverront sur des URL physiques différentes. Nous allons donc rediriger toutes les requêtes en erreur 404 (not found) vers une servlet ce qui permettra un déploiement assez transparant.
II. Configuration du serveur d’application :
Le serveur d’application est paramétrer au travers du fichier web.xml. Avantage, ce fichier est spécifique à la webapp, il n’y a donc pas de paramétrage coté serveur mais seulement coté webapp. Le fichier va ressembler à cela :
<!– Partie 1 –>
<servlet>
<servlet-name>UrlRewritingServlet</servlet-name>
<display-name>UrlRewritingServlet</display-name>
<description>Servlet de redirection et rewriting</description>
<servlet-class>disk.tools.appServer.UrlRewritingServlet</servlet-class>
<init-param>
<param-name>configFile</param-name>
<param-value>urlRewritingServlet.properties</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>UrlRewritingServlet</servlet-name>
<url-pattern>/error.jsp</url-pattern>
</servlet-mapping><!– Partie 2 –>
<error-page>
<error-code>404</error-code>
<location>/error.jsp</location>
</error-page>La partie 2 paramètre l’interception de la requête normalement en erreur et la redirige vers la page /error.jsp ce comportement est utiliser dans le cadre des redirection standard. Seulement, ici, nous avons une partie 1 qui redirige les requetes allant vers cette page d’erreur vers une servlet dont le nom est UrlRewritingServlet celle-ci étant implémenté par la classe disk.tools.appServer.UrlRewritingServlet dans l’exemple. Nous spécifions un paramètre configFile qui permettra d’indiquer à la Servlet le nom du fichier de configuration.
III. Le fichier de configuration des redirections :
Nous allons utilisé un fichier de configuration qui permettra d’indiquer les règles de redirection. Ce fichier va inclure des expressions régulières sous forme d’une liste de properties, ce mécanisme étant simple à gérer en java. Ne plus des règles de redirection, nous ajouterons une règle renvoyant vers une page spécifique les requetes à destinatination d’URL non reconnu par la servlet reproduisant ainsi le mécanisme normal d’erreur 404.
Le fichier est enregistré sous le nom UrlRewritingServlet.properties, ce nom a précédemment été indiqué dans la configuration serveur.
Son format est le suivant :# ########################################################
# DEFINITIONS DE LA REGLE PAR DEFAUT
# ########################################################
404.error = /error404.jsp# ########################################################
# REGLES SPECIFIQUES
# Format : Regex, destination
# ########################################################
rule.0 = .*MonMotif.*, /foo.jsp
rule.1 = .*TonMotif.*, /foo1.jspCette configuration renvoie toutes les requetes dont l’adresse contient le mon clef MonMotif vers la page foo.jsp et celles contenant TonMotif vers foo1.jsp. Toutes les autres requetes sont transmises à la page /error404.jsp. foo.jsp, foo1.jsp et error404.jsp sont des pages existant physiquement dans l’application ; elles serviront à présenter le résultat.
IV. La Servlet de redirection :
Pour commencer, c’est une servlet, elle hérite donc de cette classe :
public class UrlRewritingServlet extends HttpServlet {
public UrlRewritingServlet() {
super();
}
La fonction init() est appelée au chargement de la Servlet, à ce moment, celle-ci va aller lire le fichier de configuration utilisé pour les redirections. Ce fichier sera placé dans le répertoire WEB-INF de la webapp ; le chemin est donc indiqué de façon relative par rapport au chemin de la Servlet. Cette méthode n’est peut être pas optimale mais je n’ai pas mieux à proposer 🙁 . Il se peut que le chemin soit à adapter au package que vous utiliserez.
private boolean initialized; private Properties prop; public void init() {
this.initialized = false;
String file = getInitParameter(“configFile”);
if (file != null) {
String t[] = UrlRewritingServlet.class.getName().split(“\\.”);
String className = t[t.length-1];
String fileName = “Filename not found”;
try {
fileName = UrlRewritingServlet.class.getResource(className+”.class”).getPath();
fileName = fileName.substring(0,fileName.length()-className.length()-6)+”../../../../”+file;
FileInputStream is = new FileInputStream(fileName);
prop = new Properties();
prop.load(is);
} catch (Exception e) {
System.err.println(“Imposible d’acceder aux (“+fileName+”): \n”+e);
}
this.initialized = true;
}
}Reste maintenant à voir le coeur du système, la méthode doGet (ou doPost ) qui reçoit la requête à traiter :
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(“text/html”);if ( !this.initialized ) {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
PrintWriter out = response.getWriter();
out.println(“<HTML><BODY>Error : UrlRewritingServlet not initialized </BODY></HTML>”);
return;
}URL requestedURL = new URL(request.getRequestURL().toString());
String requestedHost = requestedURL.getProtocol()+”://”+requestedURL.getHost()+((requestedURL.getPort() != 80 )?”:”+requestedURL.getPort():””)+request.getContextPath();
String requestedPage = requestedURL.getPath();String destUrl = null, pValue;
int index = 0;
boolean redirectFound = false;
while (!redirectFound && (pValue = prop.getProperty(“rule.”+index)) != null ) {
StringTokenizer st = new StringTokenizer(pValue,”,”);
if ( st.countTokens() == 2) {
String regEx = st.nextToken();
if ( requestedPage.matches(regEx) ) {
redirectFound = true;
destUrl = st.nextToken().trim();
}
} else System.err.println(“Bad data : “+pValue);
index++;
}
if ( redirectFound ) {
response.setStatus(HttpServletResponse.SC_OK);
RequestDispatcher dispatcher = request.getRequestDispatcher(destUrl);
dispatcher.forward(request, response);
} else {
response.setStatus(HttpServletResponse.SC_NOT_FOUND);
destUrl = prop.getProperty(“404.error”);
if (destUrl != null) {
destUrl = response.encodeRedirectURL(requestedHost+destUrl);
response.sendRedirect(destUrl);
}
}
}Le traitement se déroule suivant les étapes suivantes :
- Si le chargement du fichier de configuration a échoué, la servlet retourne un message d’erreur standard et une réponse 404
- Sinon, elle parcours les règles définie dans le fichier et configuration jusqu’à trouver une règle correspondante ou terminer sa recherche
- Si une règle est trouvée, alors la requete est forwardée vers la page de redirection
- Sinon, une requete de redirection est soumise au navigateur vers la page d’erreur
Dans le cas d’une ré-écriture d’URL on ne souhaite pas que le navigateur soit informé que l’adresse qu’il a soumis est fausse, c’est pourquoi on utilisera une requete de forward et que la réponse sera forcé à SC_OK sans quoi il recevrait un message 404, ce qui peut être transparant pour un humain mais bienexplicite pour un robot d’indexation.
Dans le cas d’une requête en erreur dans la ré-écriture, le fait d’utiliser un sendRedirect va informé le navigateur que la page qu’il a demandé n’existe pas et le demander de charger à la place notre page d’erreur. Ainsi l’URL sera mise à jour dans le browser et la réponse en statut SC_NOT_FOUND sera explicite.
V. Pour terminer :
La source complet de la Servlet est téléchargeable dans les liens. Ceci est sans doute perfectible mais vite écrit et fonctionne parfaitement sur les site que sur lesquels je l’utilise.