Résumé

  • Le RFC 1945 de mai 1996 appelait 302 « Moved Temporarily » et exigeait une confirmation avant de rediriger automatiquement un POST. Le RFC 2068 de janvier 1997 conservait cette prudence, signalait que certains clients transformaient pourtant POST en GET et définissait 303 « See Other » pour récupérer une ressource par GET.
  • Le RFC 2616 de juin 1999 rebaptisait 302 « Found ». Il constatait que la plupart des agents existants traitaient 302 comme 303, lançant un GET vers l’adresse Location quelle que fût la méthode initiale. Il ajoutait 307 pour exprimer clairement la conservation de la méthode ; 303 existait déjà depuis 1997.
  • Le RFC 9110 de juin 2022 permet encore à un agent de changer POST en GET après 302 pour des raisons historiques. Avec 307, la méthode ne doit pas changer lors d’une redirection automatique. Ce choix décide si le contenu envoyé par le formulaire voyage aussi jusqu’à la nouvelle adresse.

Une adresse provisoire ne dit pas quoi renvoyer

Le RFC 1945 de mai 1996, consacré à HTTP/1.0, nommait 302 « Moved Temporarily ». La ressource demandée se trouvait momentanément à une autre URL, fournie dans le champ Location. Comme cette situation pouvait changer, le client devait continuer à utiliser l’adresse d’origine lors des prochaines visites. Pour une demande GET, l’histoire paraît simple : demander ici, recevoir une indication, lire là-bas.

Un formulaire soumis par POST rend l’opération plus délicate. La personne a peut-être donné des données et demandé une action. Faut-il répéter la même demande à l’adresse indiquée ? Le texte de 1996 empêchait l’agent utilisateur de rediriger automatiquement un POST sans que l’utilisateur puisse confirmer. Changer de destination peut changer les conditions dans lesquelles il a choisi d’envoyer son contenu.

Deux décisions se cachent ainsi dans une redirection. Location indique où ira la prochaine demande. La méthode et le corps de la requête décident ce qui ira là-bas. Conserver POST peut envoyer le formulaire au nouveau serveur. Passer à GET demande une représentation sans répéter l’envoi. Une flèche dessinée sur une carte ne suffit pas à décrire la seconde décision.

Le RFC original plaçait donc un frein sur l’automatisme. Il ne présumait pas qu’un clic sur « Envoyer » autorisait à transmettre les mêmes données à une autre adresse. Mais les sites voulaient aussi afficher une page de résultat après traitement du formulaire, et les navigateurs devaient prendre une décision pratique à chaque réponse.

303 disait GET ; certains clients le faisaient déjà avec 302

Le RFC 2068 de janvier 1997, première spécification HTTP/1.1, conservait le nom « Moved Temporarily » pour 302. Il demandait toujours une confirmation avant la redirection automatique d’une demande autre que GET ou HEAD. Une note mentionnait cependant une déviation observable : certains agents HTTP/1.0 changeaient un POST en GET en suivant automatiquement un 302. Le texte qualifiait ce comportement d’erroné au regard de sa règle.

Le même RFC définissait déjà 303 « See Other ». Cette réponse indiquait qu’une autre ressource devait être récupérée avec GET. Le résultat d’un script déclenché par POST était un cas principal. On peut traiter l’action à la première adresse, puis montrer au lecteur une page distincte. La nouvelle URI ne devient pas simplement un autre nom de la ressource initiale. Le code donne à l’auteur du serveur une façon précise de demander une lecture après une soumission.

Un navigateur qui transforme 302 en GET effectue une opération ressemblante sans que le serveur ait employé ce code explicite. Cela peut être commode si le formulaire a déjà été traité. Cela peut aussi laisser le nouveau point d’accès sans POST alors que le serveur attendait l’opération originale. Le même 302 portait deux scénarios. Le RFC de 1997 est précieux parce qu’il montre cette fissure au moment où elle s’ouvre, sans qu’il faille l’inférer de souvenirs tardifs.

La spécification de 1999 regarde les navigateurs en face

Le RFC 2616 de juin 1999 renomme 302 « Found ». Surtout, sa note dit que les textes de 1996 et 1997 ne permettaient pas de changer la méthode pendant la redirection, mais que la plupart des agents existants traitaient 302 comme 303 : ils faisaient un GET à l’adresse Location, quelle que fût la méthode de départ. Cette appréciation de « la plupart » vient du RFC lui-même. Le texte ne fournit pas la liste datée des versions de chaque navigateur.

La réponse des rédacteurs fut d’offrir des choix plus nets. 303 continuait à annoncer une autre ressource à récupérer en GET, notamment après un script activé par POST. Il avait été défini en 1997. Le code 307 « Temporary Redirect », présent dans la révision de 1999, permettait d’exprimer l’autre instruction : suivre une adresse temporaire tout en conservant la méthode de la requête. Pour un serveur, les deux numéros séparaient la page de résultat de la continuation d’une opération.

302 n’a pas disparu. Le RFC 2616 ajoutait même que beaucoup d’anciens agents ne comprenaient pas 303 et qu’un serveur soucieux de compatibilité pouvait employer 302, puisque la plupart y réagissaient comme à 303. La recommandation est presque ironique. Le code sémantiquement clair existait ; les navigateurs réellement installés incitaient à retourner au code surchargé.

Pour le développeur d’un formulaire, la différence a un poids immédiat. Après l’enregistrement d’une action, charger une page de confirmation en GET ne répète pas l’envoi. Si l’opération doit au contraire continuer à une adresse temporaire, il faut que le navigateur garde POST et son corps. Une réponse 302 à l’époque de clients divergents laissait une part de la suite aux habitudes des navigateurs.

La pratique entre dans le texte de 2022

Le RFC 9110 de juin 2022, consacré à la sémantique de HTTP, garde la trace de ce conflit. Après 302, un agent peut changer POST en GET pour des raisons historiques. Le mot « peut » laisse un choix au client. Si le serveur ne souhaite pas cette transformation, le document indique 307. Lorsqu’un client suit automatiquement un 307, il ne doit pas changer la méthode.

Le même texte présente 303 comme une réponse indirecte : le navigateur peut récupérer une autre ressource, en pratique par GET ou HEAD, et afficher ce résultat comme réponse à la première opération. Son explication historique décrit des agents anciens partagés entre le maintien du POST et son remplacement par GET, puis la convergence de la pratique sur la seconde solution pour 301 et 302. La norme a fini par écrire ce que le réseau faisait depuis longtemps.

Conserver POST n’est pourtant pas une vertu universelle. Cela peut acheminer le corps du formulaire jusqu’à la nouvelle URI. C’est exactement le but d’une redirection qui conserve la méthode, et la raison de vérifier à qui appartient cette destination. Passer à GET évite de renvoyer le corps, mais ne réalise pas une opération qui devait réellement se poursuivre en POST. Le choix du code répond à la transaction prévue, pas au prestige d’un numéro plus récent.

Une donnée reste hors des quatre textes : les dates précises des versions de navigateur qui ont changé de comportement. Des traces d’implémentation les établiraient. Les documents originaux suffisent à montrer la séquence décisive : la règle initiale, la divergence reconnue en 1997, le constat d’une pratique majoritaire et l’arrivée de 307 en 1999, puis la permission historique encore écrite en 2022.

Le déplacement portait aussi sur la méthode

On résume souvent les réponses 3xx à des panneaux signalant qu’une page a bougé. Le cas 302 démontre que le déplacement est aussi celui d’une action. Un POST peut contenir des données et une décision de l’utilisateur. Le répéter à une autre URI et y lire un résultat par GET ne sont pas la même opération. Location indique une adresse ; le code et le navigateur décident ce qui franchit la frontière.

Les clients installés ont rendu un comportement courant. Les rédacteurs du protocole n’ont pas pu effacer cette pratique en réaffirmant leur ancienne règle. Ils ont nommé la différence, créé un code pour conserver la méthode et fini par admettre le changement sous 302. La norme devait parler aux logiciels déjà en marche. Elle pouvait préciser l’avenir ; elle ne pouvait pas réécrire rétroactivement leurs requêtes.

La lecture opérationnelle est aujourd’hui concise : 302 peut mener un POST vers GET ; 303 demande la récupération d’une autre ressource ; 307 garde la méthode lors d’un déplacement temporaire automatique. Trois numéros voisins, trois destins possibles pour un même formulaire. L’ambiguïté du premier vient de la réponse qu’avaient déjà donnée les navigateurs.

Sources