Résumé

  • En 1997, 305 Use Proxy invitait le client à refaire sa requête par le proxy désigné dans le champ Location.
  • En 1999, la règle fut limitée à une seule requête et aux réponses du serveur d'origine. La version de 2014 l'a dépréciée pour des raisons de sécurité liées au choix d'un proxy dans l'échange HTTP.

Vous demandez un renseignement à la bonne adresse. La réponse vous dit de passer d'abord au guichet d'un inconnu, dont elle fournit le nom. Ce guichet peut recevoir la requête et la transmettre. L'ancien code HTTP 305 Use Proxy proposait exactement ce détour : le serveur répondait en désignant l'intermédiaire par lequel le client devait revenir. La destination essayait de choisir le chemin.

Dans RFC 2068, publié en janvier 1997, la définition tenait en quelques lignes. La ressource demandée devait être atteinte par le proxy indiqué dans Location, et le destinataire était censé refaire sa requête par là. Le même texte décrit le proxy comme un agent de transfert qui reçoit la demande puis l'achemine vers le serveur. Le détour change donc l'acteur placé sur la route des messages.

Un déménagement ordinaire et ce détour produisent des effets différents. 301 annonce une autre adresse pour la ressource. 305 gardait la destination et cherchait à changer le trajet du client. Choisir une étape intermédiaire touche aux paramètres du navigateur, aux contraintes du réseau et à la confiance accordée au relais. Trois phrases de protocole confiaient une décision lourde à une réponse reçue pendant la navigation.

RFC 2616, paru en juin 1999, a posé deux barrières : la consigne ne concernait qu'une requête, et seul le serveur d'origine pouvait produire un 305. Une note reconnaît que RFC 2068 avait laissé ces limites floues et qu'ignorer celles-ci entraînait des conséquences importantes pour la sécurité. La première barrière empêchait qu'une réponse modifie la politique générale de proxy du client. La seconde empêchait un relais de s'inventer le droit d'en nommer un autre au nom de la destination.

L'idée centrale restait pourtant étrange. La configuration d'un intermédiaire arrivait à l'intérieur de l'échange qu'elle voulait rediriger. RFC 7231, la révision de 2014, a déprécié 305. Son récapitulatif des changements cite expressément les préoccupations de sécurité liées à cette configuration de proxy dans la bande du protocole. Le point sensible était la nomination du relais par la réponse elle-même : le trajet de la requête devenait une décision prise dans la conversation HTTP.

RFC 9110, en 2022, garde le numéro dans le tableau des états historiques et répète qu'il est déprécié. Voilà un petit fossile du Web : une réponse pouvait autrefois tenter d'embaucher un intermédiaire pour le trajet du lecteur. Le chiffre demeure pour lire les archives, tandis que la consigne a perdu sa place dans la conduite recommandée.

L'itinéraire d'une requête compte autant que l'adresse finale. Un proxy voit la demande avant sa destination. 305 traitait ce choix comme un panneau que le serveur pouvait planter sur la route ; les textes suivants ont d'abord entouré le panneau de barrières, puis l'ont retiré du service.