Comprendre la réécriture des URL

Une URL demandée ne correspond pas toujours directement à un fichier présent sur le disque. Vous devez distinguer deux cas : Apache peut traiter la requête avec une autre ressource sans prévenir le navigateur, ou lui demander de charger une nouvelle adresse. Cette différence détermine ce que voit la personne qui consulte le site et ce que vous observez dans les réponses HTTP.

Vous avez déjà vérifié l’activation de mod_rewrite dans la leçon précédente. Ce module peut servir à appliquer des règles de réécriture, mais une règle ne signifie pas nécessairement que le navigateur sera redirigé.

Réécriture interne : le navigateur conserve l’URL

Lors d’une réécriture interne, le navigateur demande une URL, par exemple http://site.example.test/catalogue, puis Apache choisit en interne une autre ressource pour produire la réponse. Le navigateur n’a pas reçu d’instruction de changer d’adresse : la barre d’adresse reste sur /catalogue. Le contenu servi peut donc provenir d’un fichier ou d’un traitement différent du chemin visible.

Cette opération se déroule côté serveur. Elle ne provoque pas, à elle seule, une nouvelle requête du navigateur vers une autre URL. Une réécriture interne peut ainsi permettre de présenter une adresse courte ou lisible tout en servant une ressource différente ; elle ne garantit toutefois pas que cette ressource existe ni que la réponse sera une page valide.

Redirection : le navigateur reçoit une nouvelle adresse

Une redirection HTTP est une réponse indiquant au navigateur qu’il doit effectuer une requête vers une autre URL. Par exemple, si une personne demande http://site.example.test/, Apache peut répondre en indiquant une adresse commençant par https://. Le navigateur suit cette indication, envoie une nouvelle requête et affiche ensuite la nouvelle adresse dans sa barre.

Les redirections s’appuient sur une réponse HTTP de la famille 3xx, accompagnée d’une destination. À la différence de la réécriture interne, elles sont visibles dans l’échange entre navigateur et serveur et peuvent entraîner plusieurs requêtes. La redirection HTTP vers HTTPS prévue dans votre projet sera étudiée dans une leçon dédiée ; vous n’avez pas encore à la configurer.

Observer une réponse HTTP

Vous pouvez examiner les en-têtes renvoyés par l’hôte principal avec curl. Cette commande affiche les en-têtes de la réponse sans télécharger le corps de la page. Lancez-la depuis une machine où site.example.test résout vers le serveur et où le site HTTP est accessible.

curl -sS -D - -o /dev/null http://site.example.test/

Les en-têtes de la réponse HTTP sont affichés. Le statut et les en-têtes exacts dépendent de la configuration actuellement déployée ; à ce stade, aucune règle de réécriture ni redirection vers HTTPS n’a été ajoutée dans cette leçon.

Une réponse de redirection se reconnaît à son statut 3xx et à une destination annoncée, généralement dans l’en-tête Location. Une réponse qui ne présente pas ces éléments ne prouve pas qu’une réécriture interne a eu lieu : pour la constater, il faut connaître la règle configurée et comparer l’URL demandée à la ressource servie. Ici, la commande sert de point de contrôle de la réponse actuelle, pas de test d’une règle qui n’existe pas encore.

À retenir

• Une réécriture interne change le traitement côté serveur sans demander au navigateur de changer d’URL.
• Une redirection HTTP renvoie une réponse 3xx avec une destination ; le navigateur effectue alors une nouvelle requête.
• L’adresse affichée et les en-têtes HTTP sont deux indices complémentaires pour distinguer les comportements.
• Aucune règle n’est ajoutée à vos fichiers d’hôtes virtuels dans cette leçon.

Dans la leçon suivante, vous appliquerez une règle de réécriture aux pages du projet et vérifierez son effet avant tout rechargement d’Apache.