303 See Other : la redirection après un POST de formulaire

À quoi sert 303

Un 303 ne concerne pas vraiment le déplacement d'une ressource. Il s'agit de séparer une action de son résultat. Le client envoie un POST, le serveur exécute l'action, puis, au lieu de renvoyer le résultat dans la réponse du POST, il répond avec un 303 et un en-tête Location. Le client fait une nouvelle requête GET vers cet emplacement, et la barre d'adresse du navigateur se retrouve sur une URL ordinaire qui peut être mise en favori et rechargée.

La règle déterminante est la méthode : quelle qu'ait été la méthode de la requête d'origine, la requête suivante vers l'URL de Location est un GET. C'est l'inverse de 307 et 308, qui exigent que la méthode et le corps d'origine soient conservés.

Post/Redirect/Get, et le problème qu'il résout

Sans redirection après un POST, la page de résultat appartient à la requête POST, ce qui cause des problèmes familiers :

• Appuyer sur recharger soumet de nouveau le formulaire, donc la commande est passée ou le commentaire posté deux fois. Les navigateurs préviennent de cela avec une boîte de dialogue « confirmer la resoumission du formulaire », qui est elle-même une mauvaise expérience.
• La page ne peut pas être mise en favori ni partagée, car l'URL ne décrit pas le contenu.
• Le bouton précédent atterrit sur une invite de resoumission au lieu de la page précédente.

Post/Redirect/Get corrige les trois. Le POST exécute l'action et répond 303 ; le navigateur fait un GET vers l'URL de résultat ; un rechargement ne fait plus que récupérer de nouveau une page inoffensive. C'est pourquoi presque tous les frameworks ont un utilitaire « rediriger après enregistrement ».

303 contre 302 contre 307

• 302 Found est une redirection temporaire dont la gestion de la méthode est historiquement ambiguë. La plupart des clients transforment un POST en GET en la suivant, ce qui est généralement ce que vous vouliez, mais la norme ne l'impose pas. Beaucoup de frameworks émettent encore un 302 pour un post-puis-redirection et cela fonctionne en pratique.
• 303 See Other rend ce comportement explicite et obligatoire. Si votre intention est « ne répète pas mon POST, va plutôt faire un GET sur ceci », 303 le dit sans ambiguïté.
• 307 Temporary Redirect est celui à éviter ici. Il exige que le POST soit répété contre la nouvelle URL, ce qui, pour une soumission de formulaire, signifie exécuter l'action deux fois.

Une mise en garde pratique : 303 a été introduit dans HTTP/1.1, donc un client qui parle HTTP/1.0 peut ne pas le comprendre. Certains frameworks retiennent 302 par défaut pour cette raison. Sur le web moderne, c'est rarement une vraie contrainte, mais cela explique la répartition des valeurs par défaut que vous verrez selon les langages.

Où d'autre 303 apparaît

• Les API qui démarrent un travail de longue durée. Un POST lance une tâche et répond 303 avec l'URL de statut de cette tâche, ou 202 avec une URL de statut dans le corps. Les deux modèles sont utilisés ; 303 a l'avantage qu'un navigateur le suit automatiquement.
• Les flux OAuth et de connexion. Certains serveurs d'autorisation redirigent vers l'application cliente avec un 303 pour que le rappel soit récupéré avec GET quelle que soit la façon dont la requête est arrivée.
• Les configurations de données liées et de négociation de contenu qui distinguent une chose du monde réel du document qui la décrit, et utilisent 303 pour envoyer les clients de l'identifiant vers le document.

Comment l'utiliser et le vérifier

1. Après un POST réussi, renvoyez 303 avec un Location absolu pointant vers la page de résultat. Ne rendez pas le résultat en ligne.
2. Rendez la destination idempotente. Elle sera récupérée de nouveau à chaque rechargement et à chaque navigation arrière, elle doit donc être sûre à récupérer par GET de façon répétée.
3. Portez tout message ponctuel, comme « vos modifications ont été enregistrées », dans l'état de session ou un paramètre de requête plutôt que dans le corps de la redirection. Un corps de réponse 303 n'est normalement pas affiché.
4. Vérifiez le code et la cible :

   curl -si -X POST -d "name=test" https://example.com/submit | grep -Ei "^(HTTP|location)"

   Vous devriez voir HTTP/1.1 303 See Other et l'URL de résultat.
5. Suivez-la et confirmez que la seconde requête est un GET qui renvoie 200. Si vous voyez un POST répété dans vos journaux serveur, la règle est en fait un 307 et doit être corrigée.
6. Vérifiez que la destination n'est pas elle-même une redirection. Un 303 vers un 301 vers la vraie page fait trois allers-retours pour une seule soumission de formulaire.

Surveiller les points de terminaison derrière un formulaire

Un flux post-puis-redirection cassé est invisible à une vérification qui ne récupère que la page d'accueil. Le site est actif, le formulaire s'affiche, et seules les personnes qui le soumettent rencontrent l'échec. Détectez-le tôt en surveillant les points de terminaison derrière l'action, comme la page de résultat, l'URL de confirmation et la route de statut de la tâche, et en vérifiant le code de statut et le contenu attendus sur chacun. HostTracker propose 13 types de moniteurs et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux. Vérifiez ce que renvoie n'importe quelle URL avec l'outil de vérification HTTP, et lisez 301 contre 302 et le guide complet de la famille de redirections 3xx pour les codes voisins.