Mots-clé : mod_rewrite

WordPress et Permaliens : une solution / hint / astuce

Si jamais les permaliens ne fonctionnent pas :

  • via les fichiers .htaccess ;
  • que vous avez essayé de copier-coller le code qu’il vous a donné dans un fichier vhost ;
  • que vous n’y comprenez rien en règles de réécriture…

Alors essayez de mettre ce qui suit en règle de réécriture dans votre fichier vhost :

# Olivier Pons : règles pour WordPress
# faites "à la main" :
# si index, on stoppe tout :
RewriteRule ^index\.php$ - [QSA,L]
# Tester TOUTES les possibilités
# pour voir si c'est un fichier :
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d  RewriteRule . /index.php [QSA,L]

Dans mon cas leurs règles ne fonctionnaient pas car il ne voyait pas que les fichiers étaient bien là, alors j’ai ajouté la vérification en ajoutant %{DOCUMENT_ROOT}.
Oui je sais ça n’est pas l’idéal, mais comme il est écrit sur l’entrée de Facebook :

Done is better than perfect.

…And I got this thing done. Whatever.

Apache 2.4 : mod_rewrite et RewriteLog et httpd.conf : du changement

RewriteLog n’existe plus

Vous avez la description ici.

RewriteLog n’existe plus ; il faut mettre LogLevel et ensuite tracer le debug dans le errorlog via la commande :
tail -f error_log|fgrep '[rewrite:'

Mes anciens logs ressemblaient à ceci :
RewriteLog "/web/logs/bonnapizza.rewrite.log"
RewriteLogLevel 9

Maintenant ils sont tous ainsi :
LogLevel alert rewrite:trace2

Serveur Apache et mod_rewrite : mémo / astuces / hints / tips

Voici mes notes de règles de ré-écriture. Principalement des expressions régulières dont j’ai souvent besoin et que je n’ai pas en tête :

Problème :
Apache ajoute automatiquement des slashes / si c’est un répertoire.
Solution :
DirectorySlash Off
Risques de sécurite si ça n’est pas bien géré.

Problème :
Chercher une variable dans les paramètres _GET, y compris en plein milieu (les solutions en général ne sont valides que si la variable est au début dans le _GET)
Solution :
RewriteCond %{QUERY_STRING} (^|&)nomvariable=valeur(&|$)

Problème :
Prendre en compte toute une séquence de caractères sauf le slash
Solution :
RewriteRule ^/([^/]+)/?$ page.php?page=$1 [L]
ou encore prendre tout sauf le slash et le point :
RewriteRule ^/([^/\.]+)/?$ page.php?page=$1 [L]

Les filtres Apache

Il existe plusieurs filtres, qui sont passés dans l’ordre lorsqu’ils arrivent au serveur, puis sont passés exactement dans l’ordre inverse lorsqu’ils repartent vers le client (un seul m’intéresse, le premier : à l’arrivé ce sont les filtre d’entrée, et lorsque cela repart ce sont les filtres de sortie) :

  1. AP_FTYPE_RESOURCE
    Pour les filtres de contenu : cela englobe tous les types de filtres qui peuvent modifier le contenu, cela va de la décomposition de pages XML qui arrivent, à la transformation d’images ou encore à l’assemblage de contenu qui arrive en plusieurs fois. Ce type de filtre peut changer complètement la nature du contenu de la requête. Par exemple, un filtre XSLT peut transformer le contenu d’une page XML en une page HTML ou en un fichier PDF ;
  2. AP_FTYPE_CONTENT_SET
    C’est la seconde étape du filtrage du contenu, qui est principalement destinée à empaqueter le contenu, par exemple le module mod_deflate (qui applique une compression de type gzip) ;
  3. AP_FTYPE_PROTOCOL
    Le troisième filtre, : le filtre habituel a pour fonction d’insérer les entêtes HTTP au début des données qui ressortent des filtres de contenu. C’est réalisé par un filtre intégré nativement à Apache : le filtre HTTP_HEADER(la fonction ap_http_header_filter exactement), donc les applications, en général, l’ignorent.
  4. AP_FTYPE_TRANSCODE
    On s’en tape, ça ne sert pratiquement jamais.
  5. AP_FTYPE_CONNECTION
    On s’en tape, ça ne sert pratiquement jamais.
  6. AP_FTYPE_NETWORK
    On s’en tape, ça ne sert pratiquement jamais.

Le redirection interne

Il est possible dans Apache, lors de la gestion de la requête, de faire une redirection interne, c’est à dire de faire croire qu’il y a eu une redirection, mais au lieu de la renvoyer au client, et que le client demande la nouvelle URL, elle est faite en interne. Pour pouvoir faire cela, deux possibilités :

  1. Location: http://olivier.pons.free.fr/apache/
  2. Location: /apache/

La première est basée sur la nature double de l’entête Location d’un script CGI : elle force à envoyer une redirection au client, alors que la seconde fait une redirection en interne, sans envoyer quelque chose au client.

Seule la seconde possibilité nous intéresse. Il est possible de le faire de deux façons dans un module :

  1. void ap_internal_redirect(
      const char *new_uri, request_rec *r)    .

    Cette forme de redirection interne est le mécanisme à utiliser dans tous les cas à de rares exceptions près. Cette fonction crée un nouvel objet requête pour l’URL passée en paramètre, et lance la nouvelle requête comme si new_uri avait été demandée en premier lieu.

  2. void ap_internal_fast_redirect(
      request_rec *new_req, request_rec *r)

    Cette fonction clone une structure existante new_req dans la requête en cours afin de pouvoir mettre en place une nouvelle requête et simuler le fait qu’on lui passe le contrôle. Ce mécanisme est parfois utilisé pour promouvoir une sous-requête en requête principale. Ce qui est important de noter c’est qu’on ne repart pas de zéro, donc on ne refait pas complètement la requête.

Le module mod_rewrite

Apache se souvient des modèles, ou groupes passés dans les règles de réécriture, et on peut les rappeler grâce à la directive $N, avec (0 <= N <= 9).

Apache se souvient aussi des derniers ordres passés dans les conditions de réécriture, et on peut les rappeler grâce à la directive %N, avec (0 <= N <= 9).

Un exemple concret :

  1. RewriteCond %{HTTP_HOST} ^(www\.)+mamemeamoi\.(com|fr) [NC]
  2. RewriteCond %{REQUEST_URI} ^(.*)\.php$ [NC]
  3. RewriteRule ^/(.*) /$1?IDP=mameme [PT,QSA,S=4]

Traduit en clair, cela signifie :

  1. Si on vient ici à partir d’une adresse telles que www.mamemeamoi.com ou encore www.mamemeamoi.fr voire mamemeamoi.fr alors c’est bon on continue les conditions pour la règle à venir
  2. Si on demande à voir une page qui se termine par php alors c’est bon on continue les conditions pour la règle à venir
  3. Si on est arrivé jusqu’ici c’est que toutes les conditions ont été validées => on applique la règle qui est, traduite en Français :
    1. ^/(.*) /$1?IDP=mameme : on ajoute à l’URI, quelle qu’elle soit, les paramètres IDP=mameme ;
    2. Directive [PT] : on applique cette URI en interne de manière à faire croire à tout ce qui suit, y compris une fois que les règles de réécriture sont terminées, que c’est vraiment cette adresse qui a été demandée, donc les autres modules agiront aussi en conséquence ;
    3. Directive [QSA] : sur l’URI appliquée, on y fait suivre les paramètres qui se trouvaient après le ?, les paramètres _GET en php. Par exemple si on a demandé /t.php?i=3, on se retrouve avec l’URI finale /t.php?i=3&IDP=meme, alors que sans la directive QSA, on se retrouve avec l’URL finale /t.php?IDP=meme ;
    4. Directive [S=4] : on demande de sauter les 4 règles de réécriture qui suivent, et on appliquera celles qu’il y a après (s’il y en a).

Maintenant, voyons si on avait changé la règle de réécriture par :

  1. RewriteCond %{HTTP_HOST} ^(www\.)+mamemeamoi\.(com|fr) [NC]
  2. RewriteCond %{REQUEST_URI} ^(.*)\.php$ [NC]
  3. RewriteRule ^/(.*) /%1%2/$1

Regardez bien : il y a le sigle %1 mais aussi le sigle $1. En réalité le %1 est remplacé par ce qu’il y a dans les parenthèses rencontrées dans la condition de réécriture. Et en partant de la première condition ! A l’inverse, le $1 est remplacé par ce qu’il y a dans les parenthèses rencontrées dans la règle de réécriture. Ainsi si on demande l’URI http://www.mamemeamoi.com/popo.php, elle sera transformée en http://www.com/popo.php, et si on demande l’URI http://mamemeamoi.com/popo.php, elle sera transformée en http://com/popo.php. Ce qui ne sert à rien d’autre que de montrer un exemple. Mais imaginez ce que vous pouvez faire !

MPM : Multi-Processing-Modules

A la fin de la phase de démarrage, après que la configuration ait été lue, le contrôle général d’Apache est passé à un module de gestion de processus, le Multi-Processing-Module.

Un MPM est une interface entre le serveur Apache qui tourne et l’OS sous-jacent. Son rôle principal est d’optimiser Apache en fonction de la plateforme sur laquelle le serveur tourne. Comme indiqué dans le titre, le MPM est lui-même un module. C’est, à l’inverse de tous les autres, modules, un module au niveau système et non pas un module au niveau applicatif.

Il exite plusieurs MPM‘s.

  • MPM Prefork : c’est un modèle non orienté thread, ressemblant fortement aux mode de fonctionnement des serveurs Apache 1.x
  • MPM Worker : modèle orienté thread. Il a une plus grande souplesse et s’adapte beaucoup mieux en fonction de la demande. Il est particulièrement plus performant que le modèle précédent, notamment avec certains types d’applications.

Tous les deux souffrent d’une limite qui affecte tous les serveurs très demandés. Alors que le HTTP Keepalive est nécéssaire pour réduite le nombre de connexions TCP et la surcharge réseau, il « ligotte » le processus ou le thread d’un serveur pendant toute la durée de la connexion, tant que le Keepalive est actif.

Le nombre de threads disponibles est une ressource critique pour la plateforme sur laquelle est le serveur. Par exemple, un serveur basé sur le module MPM Worker est réellement occupé s’il doit se charger de gérer plusieurs dizaines de milliers de demandes simultanément. L’OS sous-jacent peut parfois arriver à court de threads.

C’est pourquoi un nouveau MPM est en cours de développement. Il en est à un stade avancé, mais pas encore au stade de production, stade qu’ont atteint les deux modules cités précédemment. C’est le MPM basé sur des événements, le Event MPM. Notez bien que ce type de module ne fonctionnera pas en mode sécurisé (https). Par contre, il aura la possiblité de gérer un nombre nettement plus important de hits que les autres modules.

Apache : le lancement du processus

Le démarrage d’Apache se décompose en deux temps :

  1. démarrage ;
  2. mode opérationnel.

C’est à dire que quelque chose peut porter à confusion, mais c’est normal : le code de configuration est appelé deux fois.

La première fois c’est uniquement pour vérifier si toute la configuration est valide, et la seconde fois, c’est pour le démarrage réel, la phase « opérationnelle ».

La plupart des modules peuvent ignorer ce comportement, mais il possible que, par exemple, si votre module charge du code dynamiquement au démarrage, il n’ait pas besoin de le faire deux fois. Les modules qui veulent faire cela peuvent, par exemple, déclarer un drapeau statique et, vérifier lors de l’appel, s’il est déjà initialisé. Si ce n’est pas le cas, le mettre à vrai, et charger tout ce qu’il faut. Dans les autres cas, ne rien faire.

Notez bien qu’au démarrage, Apache n’a qu’un seul thread actif et est root, ce qui signifie qu’il est possible de faire tout et n’importe quoi, mais après le démarrage, il ne sera plus jamais root, par mesure de sécurité.

Développement de module

Ce paragraphe est un résumé de mes notes personnelles, pour que je puisse m’en sortir si je reconsulte ce que j’ai fait dans 6 mois.

Lorsqu’on veut développer un module, il va falloir taper du code. Celui-ci se trouvera à plusieurs endroits possibles (dans le cadre du développement d’un module) :

  • lors des phases de lecture de configuration ;
  • lors des phases de gestion de la requête client.

Le gestion de la requête client, elle-même, se décompose en plusieurs phases et il faudra préciser parmi laquelle de ces phases, il faudra appeler une routine qu’on aura développé. Le problème c’est que les créateurs d’Apache ont tellement optimisé le code, qu’il y a des rotations qui se font entre les appels des fonctions, alors ils ont décidés de créer, grossièrement, des « groupes » auxquels on pourra associer nos fonctions. Par exemple, si on veut qu’une fonction A soit appelée de manière certaine avant une fonction B, on dit que la fonction A doit appartenir au groupe HOOK_REALLY_FIRST, et la B au groupe HOOK_MIDDLE, qui sera éxécuté forcément après. Il faut bien avoir en tête que si jamais un autre mec fait un module en C dans lequel il a enregistré une fonction A’ dans le groupe HOOK_REALLY_FIRST, il sera possible, que dans certains cas sa fonction A’ soit appelée avant la fonction A, et dans d’autres cas, l’inverse. Ce dont on est sûr, c’est que la B sera éxécutée après les fonctions du groupe HOOK_REALLY_FIRST.