Nov/090
Redirection nginx des vues par locale
L’internationalisation demande à ce que l’on serve des fichiers différents selon la locale sélectionnée. Ces fichiers sont générés par une pré-génération via Rake
.
Maintenant, il faut être capable de choisir le fichier à fournir à l’utilisateur. Nous utiliserons principalement la sélection de la locale par paramètre d’URL
, ceci afin de respecter des principes REST
d’auto-suffisance des URL
et parce que les accès aux ressources se font principalement par Ajax
et sont donc cachées à l’utilisateur et automatisable simplement.
les URL
seront donc de la forme suivante :
http: /view.html
-> page avec locale par défaut ->filesys: /www/view_en.html
http: /view.html?lang=fr
-> page traduite en français ->filesys: /www/view_fr.html
Pour cela, il est nécessaire de traduire un paramètre de requête en un chemin dans le système de fichiers directement au niveau du serveur web : nginx
nous fourni un module de réécriture comme sur tout autre serveur.
On le met en oeuvre de la manière suivante :
http { server { 1 rewrite_log on; 2 if ($args ~* lang=(..)) { 3 set $lang $1; 4 rewrite ^(.+)\.html$ $1_$lang.html last; } ...
- On active le moteur de réécriture (déjà intégré)
- On utilise un expression régulière avec capture afin de savoir si l’
URL
contient un paramètre de choix de langue, - on récupère la langue (limitée à 2 caractères, donc
fra
sera tronqué enfr
) - on réécrit le nom de la ressource pour inclure la locale
Remarque : la réécriture ne concerne pas les paramètres, donc la règle de réécriture est correcte et conserve les paramètres.
Oct/090
Debug du mode rewrite sous nginx
Pour voir ce qui est fait au niveau du module rewrite
de nginx
, ne pas oublier de modifier la configuration de la manière suivante :
décommenter la trace de type notice
:
error_log logs/error.log notice;
déclencher le mode rewrite au niveau du serveur HTTP
:
http { rewrite_log on;
Les étapes de réécriture apparaissent dans le fichier de trace /etc/nginx/logs/error.log
.
Jul/090
Installation d’un serveur web
La boucle de réaction aux requêtes utilisateurs est trop permissive et permet un accès fichier pour toute URL non reconnue.
On la transforme donc suivant le code suivant :
case Path of "test" -> ctrl_test:handle_http(Req, Params, Data); _ -> Req:respond({501, [], []}) end.
Seulement, les fichiers statiques devront continuer à être fournis au client. Pour cela, on installe un serveur web en frontal du service, et Nginx sera utilisé à cette fin.
En utilisant Arch, l’installation est simple :
yaourt -Sy nginx
On modifie la configuration afin de le faire pointer vers le répertoire des ressources statiques et également pour faire le routage vers notre serveur applicatif Mochiweb. La configuration est stockée dans le fichier /etc/nginx/conf/nginx.conf
et on la modifie comme suit :
server { listen 80; server_name localhost; # Serve static files location ~ ^/assets/ { root /d/apps/ercm/priv/www; expires 30d; } # Serve html views location ~ \.html$ { root /d/apps/ercm/priv/www; } # Anything else is redirected to Mochiweb location / { proxy_pass http://127.0.0.1:8000; }
Pour le démarrer, rien de plus simple :
sudo nginx
Le site doit fonctionner comme avant. Toute URL ne commençant pas par /assets
sera redirigée vers Mochiweb.
Attention ! Il s’agit d’une configuration de développement/test et non pas d’un exemple de ce qu’il faut faire en production, bien évidemment.