Je sais, ca fait un bail que j'avais plus bloggué. A côté mr_pouit et gpocentek ont même l'air productifs (mais bon, je peut toujours me dire que je suis plus productif que Lutin tout de même :p).
Enfin bref, la date et l'heure sont parfaites pour annoncer mon billet cadeau de noël sur cette nouvelle feature du serveur web nginx, try_files.

Tout commence plus ou moins sur ce thread par un Igor Sysoev (le développeur de nginx donc) qui une fois de plus râle sur l'utilisation abusive des blocs if dans les fichiers de config, notamment lors de tests d'existence d'un fichier. Igor annonce donc l'implémentation d'une fonctionnalité pour rendre tout cela plus propre. La syntaxe est rapidement définie et le nom est choisi après une courte discussion : try_files.

Mais de quoi s'agit-il exactement ? C'est assez simple, prenez ce bout de config :

location / {
    if (-f $request_filename) {
        break;
    }
 
    if (-f $request_filename/index.html) {
        rewrite (.*) $1/index.html break;
    }

    if (-f $request_filename.html) {
        rewrite (.*) $1.html break;
    }

    if (!-f $request_filename) {
        proxy_pass http://mongrel;
        break;
    }
  }

Ce qui donne : pour toutes les URLs (car elles correspondent toutes à "/"), on teste si le fichier demande existe. Si oui, on arrête de lire la suite des règles et on sert le fichier. Sinon, on continue et teste après si un dossier correspondant au fichier demandé existe avec le fichier "index.html" à l'intérieur. Si c'est le cas on arrête la suite pour le servir (avec un rewrite). On fait ensuite de même en cherchant un fichier correspondant au nom de fichier demandé suivi de ".html".
Si tout cela ne marche pas (notez qu'on teste si le fichier n'existe pas encore une fois, ce qui pourrait être omis) on passe la requête au serveur nommé "mongrel" (défini auparavant dans un bloc upstream).
Malgré mes piètres explications, vous l'aurez compris, on cherche à servir les "vrais" fichiers et les fichiers de cache avant de passer en dernier recours la requête au serveur d'application (qui héberge donc notre appli qu'elle soit en ruby, python, php (avec fastcgi éventuellement) ou autre).

Ce type de config est extrèmement courant pour les applications rails ou nginx est couplé avec mongrel ou thin. Et c'est donc cela que try_files améliore. Voyez plutôt :

location / {
    try_files $uri  $uri/index.html  $uri.html @mongrel;
}

location @mongrel {
    proxy_pass     http://mongrel;
}

Pas mal non ? (sisi, quand même !) On donne simplement a try_files des urls à essayer. Le dernier argument est une "named location" (emplacement nommé ?), de type @nom. (les named location existent depuis longtemps mais ne sont pas très répandus, au grand dam d'Igor).
Ce dernier paramètre sera donc utilisé quand les autres auront échoué (les named locations "existent" toujours). Je ne sais pas si ce "fallback" est obligatoire ou si une erreur 404 est envoyé au cas ou tous les essais de try_files échouent mais il semble nécessaire d'après Igor.
Je pense qu'Igor espère aussi une plus grande utilisation des named locations grâce à cette feature.

Cette directive est donc arrivée dans nginx 0.7.27 (la branche de développement), et un patch est disponible pour nginx 0.6.34 (bon, faut que je migre mon 0.5.x de prod moi....).
Ajoutez à cela la possibilité d'utiliser des variables dans les directives fastcgi_pass et proxy_pass (ce qui permettra de rendre ses fichiers de config plus réutilisables), toujours depuis la version 0.7.27.
Pour plus d'infos vous pouvez donc consulter la mailing-list de nginx (notamment les threads sus-cités) en attendant qu'une âme charitable mette à jour le wiki.

Mais, que faites vous encore sous Apache ou Lighttpd ?

PS: Joyeux Noël à tous les utilisateurs de serveurs webs, d'un côté ou de l'autre du tuyau :-)