Date de publication du RFC : Juin 2014
Auteur(s) du RFC : J. Reschke (greenbyte)
Expérimental
Première rédaction de cet article le 17 juin 2014
Le protocole HTTP définit plusieurs codes de
retour pour une redirection (« la ressource que tu cherches n'est pas
ici, va voir là »). La section 6.4 du RFC 7231 classe ces trois codes de retour en notant que
deux désignent des redirections temporaires (302 et 307) et qu'un
désigne une redirection permanente (301). Deux codes permettent au
client HTTP de remplacer, pour la nouvelle requête, la méthode
POST
par un GET
(301 et 302), un
autre ne le permet pas (307). Si vous avez suivi, vous avez noté qu'il
manquait un code voulant dire « redirection permanente mais sans
changer la méthode HTTP ». C'est l'objet du nouveau code décrit dans
ce RFC, le 308 (depuis normalisé dans le RFC 7538).
Donc, 308 veut dire (section 3 de notre RFC) que la ressource Web
convoitée a changé de place, que c'est permanent et que le client HTTP
devrait donc aller chercher la ressource au nouvel endroit
et, s'il le peut, modifier sa base de données
(dans le cas d'un crawler,
par exemple, ou dans celui d'un navigateur qui modifie les
marque-pages). Où est indiqué « le nouvel endroit » ? Par
l'en-tête Location:
de la réponse HTTP
(cf. section 7.1.2 du RFC 7231). Il est recommandé d'inclure un petit texte en
HTML fournissant un autre moyen de suivre la
redirection, si le client HTTP n'a pas compris le 308. Bref, le 308
est très proche du 301, à la seule exception près qu'un client n'a pas
le droit de changer la méthode HTTP (POST
,
GET
, etc) utilisée. Le nouveau code est désormais
dans le registre IANA.
Est-ce que l'information comme quoi il y a redirection peut être mémorisée dans les caches ? Il n'y a pas de mécanisme parfait pour cela mais lesdits caches sont invités à regarder le RFC 7234.
Ajouter un nouveau code HTTP peut provoquer des problèmes de
déploiement (section 4). En effet, la section 6 du RFC 7231 dit que les codes inconnus commençant par 3
doivent être traités comme le code 300 (qui annonce des choix
multiples, en cas de négociation de contenu). Au début, 308 va être
inconnu de tous les clients HTTP et sera donc mal interprété. (Vous pouvez tester votre navigateur ici.) Il n'y
aura pas de redirection automatique. En attendant que tous les clients
soient mis à jour, le webmestre prudent n'utilisera 308 que s'il
connait les clients utilisés, ou s'il sait que l'absence de
redirection automatique n'est pas trop grave. Le RFC déconseille
formellement de faire varier la réponse selon le client (ou selon ce
qu'on croit être le client, rappelez-vous que le champ
User-Agent:
peut être trompeur), cela rend le Web
trop difficile à déboguer.
Une façon de s'en tirer pourrait être via le code HTML suggéré plus haut. Par exemple :
HTTP/1.1 308 Permanent Redirect Content-Type: text/html; charset=UTF-8 Location: http://example.com/new Content-Length: 454 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Permanent Redirect</title> <meta http-equiv="refresh" content="0; url=http://example.com/new"> </head> <body> <p> The document has been moved to <a href="http://example.com/new"> http://example.com/new</a>. </p> </body> </html>
Ainsi, un navigateur Web qui ne comprend pas le
308 sera redirigé, via le <meta http-equiv="refresh" ...
.
Où en sont les mises en œuvre ? Vous pouvez tester sur le test de libcurl. Pour les navigateurs et autres clients :
Enfin, je signale deux bons articles sur le 308, un en français et un en anglais. Ce code était expérimental à l'époque et est désormais normalisé, depuis le RFC 7538.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)