Réécriture (Rewrite) et .htaccess : différences et points d’attention en migrant de NGINX et Apache vers Caddy dans ServBay

Informations de contexte

La réécriture d’URL (souvent appelée Rewrite ou URL rewriting), également connue sous le nom de pseudo-static, est une technique permettant de modifier dynamiquement les URLs des requêtes au niveau du serveur web. Elle permet, par exemple, de transformer une URL d’origine accédée par l’utilisateur ou un moteur de recherche (comme /?page=123) en une autre URL plus propre (comme /posts/123/), tout en laissant à l’utilisateur l’impression d’accéder directement à l’URL réécrite dans la barre d’adresse du navigateur. Cette technique est largement utilisée pour :

Embellir la structure des URLs : Créer des URLs “propres” ou “pretty” plus lisibles, mémorisables et facilement partageables.
Améliorer le SEO : Les moteurs de recherche préfèrent des URLs descriptives et bien structurées.
Cacher les détails d’implémentation internes : Éviter d’exposer chemins de fichiers ou paramètres de requête, renforçant la sécurité.
Uniformiser les URLs : Forcer l’utilisation d’un certain format d’URL (avec ou sans www, en HTTPS, etc.).
Mettre en place un routage centralisé : Les frameworks web modernes utilisent massivement la réécriture pour rediriger toutes les requêtes vers un unique fichier d’entrée (comme index.php), lequel prendra en charge le traitement via le framework.

Savoir comprendre et configurer des règles de réécriture est donc une compétence essentielle pour tout développeur web.

Support de NGINX et Apache dans ServBay

ServBay intègre et supporte complètement NGINX et Apache comme serveurs web. L’utilisateur peut facilement basculer d’un serveur à l’autre selon les besoins de son projet ou ses préférences.

Pour en savoir plus sur le changement de serveur web par défaut, consultez : Comment définir le serveur web par défaut

ServBay propose aux développeurs plusieurs serveurs web populaires, notamment Caddy, NGINX et Apache. Pour simplifier la configuration de l’environnement de développement local, ServBay préconfigure déjà les règles de réécriture courantes pour Caddy et NGINX, couvrant la grande majorité des besoins des frameworks et CMS web modernes. Ainsi, pour de nombreuses applications populaires comme WordPress, Laravel, Symfony (toutes basées sur PHP), il est en général inutile de modifier ou d’ajouter manuellement des règles de réécriture sur ServBay pour un fonctionnement immédiat, dès la première utilisation (“plug-and-play”).

Cependant, si vous êtes habitué à utiliser Apache ou NGINX et envisagez de migrer vos sites ou projets existants vers Caddy intégré à ServBay, il est crucial de bien comprendre les différences de configuration des règles de réécriture entre ces serveurs. Ce guide détaille les différences entre Apache, NGINX et Caddy concernant la réécriture, et liste les précautions à prendre lors de la migration.

Règles de réécriture prêtes à l’emploi : atout de ServBay

Point important

L’un des principes de conception de ServBay consiste à simplifier la mise en place et la configuration de l’environnement de développement local. Pour la plupart des applications et frameworks web répandus, ServBay fournit déjà une configuration complète des règles de réécriture. Cela signifie que sur ServBay, vous n’aurez généralement pas besoin d’écrire ou de modifier manuellement les règles de réécriture pour faire fonctionner ces applications. Ces configurations essentielles, mais parfois complexes, sont traitées de façon transparente par ServBay.

Si vous migrez un site précédemment hébergé sur Apache ou NGINX vers l’environnement Caddy de ServBay, et devez gérer des règles de réécriture personnalisées complexes, nous vous recommandons de consulter les guides de migration complets suivants :

Présentation des règles de réécriture selon le serveur web

Chaque serveur web possède une structure et une syntaxe qui lui sont propres pour la configuration des réécritures. Comprendre ces différences est indispensable lors d’une migration inter-serveur. Cette section récapitule brièvement les méthodes de configuration de la réécriture pour Apache, NGINX et Caddy.

Le fichier .htaccess d’Apache

Le serveur HTTP Apache utilise le fichier .htaccess pour ses règles de réécriture. Il s’agit d’un fichier de configuration distribué, généralement placé à la racine ou dans un sous-dossier du site. Il permet de surcharger la configuration principale du serveur au niveau du dossier, affectant (sauf exception) ce dossier et tous ses sous-dossiers. Apache s’appuie sur le module mod_rewrite pour gérer la réécriture.

Exemple d’utilisation basique

Voici un exemple typique de fichier .htaccess redirigeant toutes les requêtes dont le fichier ou le dossier n’existe pas vers index.php — scénario commun à de nombreux frameworks PHP et CMS.

apache

# Activer le moteur de réécriture
RewriteEngine On

# Si le fichier ou le répertoire demandé n’existe pas, appliquer la règle de réécriture
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# Réécrire toutes les requêtes vers index.php en conservant la chaîne de requête (query string)
RewriteRule ^(.*)$ index.php [L,QSA]

Explication :

RewriteEngine On : Active la réécriture dans le dossier courant.
RewriteCond %{REQUEST_FILENAME} !-f : Condition : si le chemin du fichier demandé (%{REQUEST_FILENAME}) n’est pas un fichier existant (!-f).
RewriteCond %{REQUEST_FILENAME} !-d : Condition : si le chemin du fichier demandé n’est pas un dossier existant (!-d).
RewriteRule ^(.*)$ index.php [L,QSA] : Règle de réécriture :
- ^(.*)$ : Correspond à tout chemin d’URL.
- index.php : Réécrit l’URL correspondante vers index.php.
- [L] : “Last”, cette règle est la dernière, la réécriture s’arrête ici.
- [QSA] : “Query String Append”, la chaîne de requête d’origine est appendue à l’URL réécrite.

Les règles de réécriture NGINX

NGINX configure ses règles de réécriture dans un fichier principal (nginx.conf) ou dans des fichiers de configuration spécifiques à chaque site, généralement situés dans conf.d ou sites-available/sites-enabled. Les règles se placent souvent dans un bloc server (pour un hôte virtuel) ou un bloc location (pour un chemin d’URL précis). Le module ngx_http_rewrite_module de NGINX propose une réécriture puissante, avec une syntaxe différente d’Apache.

Exemple d’utilisation basique

Voici un extrait de configuration NGINX reproduisant la logique de redirection vers index.php :

nginx

server {
    listen 80;
    server_name servbay.demo; # Exemple de domaine ServBay

    root /Applications/ServBay/www/demo; # Exemple de racine du site

    # Tenter, dans l’ordre, de trouver le fichier demandé ou le dossier, sinon réécrire vers index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Gestion des fichiers .php, redirection vers PHP-FPM/FastCGI
    location ~ \.php$ {
        # Vérification de l’existence du fichier pour éviter toute exécution arbitraire
        try_files $uri =404;
        include fastcgi_params;
        # Chemin du socket FastCGI PHP par défaut dans ServBay
        fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Explication :

location / : Correspond à la racine du site.
try_files $uri $uri/ /index.php?$query_string; : Directive commune :
1. Cherche si le fichier ($uri) existe.
2. Cherche si le dossier ($uri/) existe.
3. Si aucun des deux, réécrit la requête vers /index.php et ajoute la chaîne de requête originale (?$query_string).
location ~ \.php$ : Pour toute URL se terminant par .php.
fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock; : Délègue les requêtes PHP vers le processeur PHP FastCGI par défaut de ServBay.

Les règles de réécriture Caddy

Caddy utilise son propre fichier de configuration, le Caddyfile, pensé pour être lisible, épuré et puissant. La syntaxe diffère énormément de celle d’Apache ou NGINX, mais vise à être plus intuitive. Les réécritures s’effectuent via la directive rewrite associée à des “matchers” ou filtres de correspondance.

Exemple d’utilisation basique

Exemple d’un Caddyfile réalisant une logique similaire de redirection vers index.php :

bash

servbay.demo { # Exemple de domaine ServBay
    root * /Applications/ServBay/www/demo # Exemple de racine du site

    # Rediriger les requêtes PHP vers le processeur PHP FastCGI par défaut de ServBay
    php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock

    # Activer le service de fichiers statiques
    file_server

    # Définir un matcher @notStatic : la ressource demandée (fichier ou dossier) n’existe pas
    @notStatic {
        not {
            file {
                # Cherche le fichier {path} ou le dossier {path}/
                # Si rien n’est trouvé, le matcher (@notStatic) s’active
                try_files {path} {path}/
            }
        }
    }

    # Si le matcher @notStatic est actif, réécriture interne vers /index.php
    rewrite @notStatic /index.php
}

Explication :

servbay.demo { ... } : Bloc définissant un site pour le domaine servbay.demo.
root * /Applications/ServBay/www/demo : Définit la racine du site. * : sur tous les chemins.
php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock : Directive intégrée Caddy pour router les requêtes .php (et autres descendants PHP) vers le FastCGI.
file_server : Directive simple, sert les fichiers statiques du dossier.
@notStatic { ... } : Déclare un “matcher” nommé notStatic.
not { file { try_files {path} {path}/ } } : Active le matcher si ni le fichier ni le dossier ne sont trouvés.
rewrite @notStatic /index.php : Si le matcher est validé, réécriture interne vers /index.php.

Dans la configuration par défaut de ServBay, la directive php_fastcgi inclut déjà une logique équivalente à try_files, et ServBay prépare automatiquement la structure de base du Caddyfile du nouveau site pour un usage sans paramétrage supplémentaire. L’exemple ci-dessus illustre la logique possible avec la syntaxe native de Caddy.

Points d’attention lors de la migration depuis Apache ou NGINX vers Caddy dans ServBay

Lors de la migration de sites depuis Apache ou NGINX vers Caddy dans ServBay, la conversion des règles de réécriture est une étape critique. ServBay préconfigure la majorité des scénarios courants, mais pour des projets avec des règles sur-mesure, il faudra comprendre et reconfigurer manuellement ces règles.

Consultez nos documents détaillés sur la migration :

Voici les principales différences à prendre en compte :

Syntaxe et emplacement des règles de réécriture :
- Apache : .htaccess (fichier distribué au niveau des dossiers) ou fichier principal (httpd.conf/config site). Syntaxe fondée sur des expressions régulières via RewriteRule et RewriteCond.
- NGINX : Fichier de configuration principal (nginx.conf) ou config de site (centralisé). Association des directives location, rewrite, if, try_files, syntaxe très différente d’Apache.
- Caddy : Caddyfile centralisé. Utilisation de la directive rewrite avec des matchers puissants (file, path, header, etc.) : syntaxe concise et lisible.
- Conversion : Nécessité de transposer manuellement les règles .htaccess d’Apache ou les logiques location/rewrite/try_files de NGINX dans la logique du Caddyfile. Pas d’outil automatique parfait : la compréhension du fonctionnement de chaque système et l’appui sur la documentation Caddy (section rewrite et matchers) sont indispensables.
Structure du fichier de configuration :
- Apache : Autorise des configurations différentes dans chaque dossier via .htaccess ou bien en centralisé via le VirtualHost principal.
- NGINX : Structure centralisée dans nginx.conf et les fichiers inclus, organisée par blocs server et location.
- Caddy : Organisation centralisée dans le Caddyfile, chaque hôte (adresse) ayant son bloc propre et toutes les instructions à l’intérieur. Structure plus plate et lisible que NGINX.
Correspondance entre modules et directives :
- Apache et NGINX disposent de vastes ensembles de modules et de directives. Caddy offre un jeu de fonctionnalités étoffé, mais avec des implémentations et des noms parfois différents. Par exemple, le module mod_rewrite d’Apache est remplacé par la directive rewrite et les matchers chez Caddy ; la directive try_files de NGINX a son équivalent dans le matcher file de Caddy, ou sous forme intégrée (php_fastcgi).
- Lors de la migration, reportez-vous à la documentation Caddy pour trouver l’équivalent de chaque fonctionnalité et en appréhender la syntaxe.
Comportements par défaut et priorités d’application :
- Chaque serveur gère l’ordre de traitement et les priorités de façon différente. Apache a sa logique pour le traitement des .htaccess, NGINX gère l’ordre des blocs location, Caddy exécute les directives dans l’ordre du fichier (par conception, la séquence importe).
- Après migration, testez systématiquement l’ensemble des chemins d’URL pour valider la conformité des réécritures. Attention : la configuration par défaut de Caddy sur ServBay intègre fréquemment les règles de base requises — évitez les redondances ou conflits.

Conclusion

ServBay offre trois solutions serveurs pour le développement local : Caddy, NGINX et Apache. Bien que ServBay préconfigure pour Caddy et NGINX la plupart des scénarios courants de réécriture d’URL (permettant la prise en main immédiate des principales applications), les développeurs habitués aux personnalisations d’Apache ou NGINX devront impérativement se familiariser avec les différences de configuration s’ils migrent vers Caddy.

Apache s’appuie sur une configuration distribuée via .htaccess et les directives RewriteRule/RewriteCond ; NGINX utilise des fichiers centralisés avec des blocs location/rewrite/try_files ; Caddy privilégie un Caddyfile épuré, associé à la directive rewrite et à des matchers puissants.

La clé de la migration réside dans la conversion fidèle des logiques de réécriture Apache/NGINX en syntaxe Caddyfile. Si cela demande une période d’apprentissage, la configuration épurée de Caddy et les modèles préparés par ServBay, ainsi que ses guides détaillés de migration, facilitent considérablement le processus. Nous espérons que cet article vous aidera à maîtriser ces différences et à tirer pleinement parti de ServBay pour votre développement web local.

Réécriture (Rewrite) et .htaccess : différences et points d’attention en migrant de NGINX et Apache vers Caddy dans ServBay ​

Règles de réécriture prêtes à l’emploi : atout de ServBay ​

Présentation des règles de réécriture selon le serveur web ​

Le fichier .htaccess d’Apache ​

Exemple d’utilisation basique ​

Les règles de réécriture NGINX ​

Exemple d’utilisation basique ​

Les règles de réécriture Caddy ​

Exemple d’utilisation basique ​

Points d’attention lors de la migration depuis Apache ou NGINX vers Caddy dans ServBay ​

Conclusion ​

Réécriture (Rewrite) et .htaccess : différences et points d’attention en migrant de NGINX et Apache vers Caddy dans ServBay

Règles de réécriture prêtes à l’emploi : atout de ServBay

Présentation des règles de réécriture selon le serveur web

Le fichier .htaccess d’Apache

Exemple d’utilisation basique

Les règles de réécriture NGINX

Exemple d’utilisation basique

Les règles de réécriture Caddy

Exemple d’utilisation basique

Points d’attention lors de la migration depuis Apache ou NGINX vers Caddy dans ServBay

Conclusion