Quelle est la différence entre une redirection 302 et 307?
Quelle est la différence entre une réponse 302 FOUND et une réponse 307 TEMPORARY REDIRECT HTTP?
La spécification W semble indiquer qu'ils sont tous deux utilisés pour des redirections temporaires, et aucun ne peut être mis en cache à moins que la réponse ne le permette spécifiquement.
La différence concerne les demandes de redirection POST, PUT et DELETE et les attentes du serveur vis-à-vis du comportement de l'agent utilisateur ( RFC 2616 ):
Remarque: RFC 1945 et RFC 2068 spécifient que le client n'est pas autorisé à modifier la méthode sur la demande redirigée. Cependant, la plupart des implémentations d'agent d'utilisateur existantes traitent 302 comme s'il s'agissait d'une réponse 303, en effectuant une opération GET sur la valeur du champ Location, quelle que soit la méthode de requête d'origine. Les codes d’état 303 et 307 ont été ajoutés pour les serveurs qui souhaitent préciser clairement le type de réaction attendue du client.
Lisez également l’article de Wikipedia sur = 30 codes de redirection .
307 est dû au fait que les agents utilisateurs ont adopté comme comportement de facto de prendre POST demandes recevant une réponse 302 et envoyant une demande GET à l'en-tête de réponse Location.
C’est le comportement incorrect - seulement un 303 devrait faire en sorte qu'un POST se transforme en GET. Les agents utilisateurs doivent (mais ne doivent pas) s'en tenir à la méthode POST lors de la demande de nouvelle adresse URL si la demande POST d'origine a renvoyé un 302.
307 a été introduit pour permettre aux serveurs d'indiquer clairement à l'agent d'utilisateur qu'une modification de méthode ne devrait pas être effectuée par le client lorsqu'elle suit l'en-tête de réponse Location.
Un bon exemple de 307 Internal Redirect en action est le cas où Google Chrome rencontre un appel HTTP vers un domaine qu’il considère comme nécessitant une sécurité de transport stricte.
Le navigateur redirige de manière transparente, en utilisant la même méthode que l'appel d'origine.
EXPECTED for 302: la redirection utilise la même méthode de requête POST sur NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL
ACTUAL pour 302, 303: la méthode de demande de changement de redirection de POST à GET sur NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
ACTUAL pour 307: la redirection utilise la même méthode de requête POST sur NEW_URL
CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL
- 301: redirection permanente: l'URL est ancienne et doit être remplacée. Les navigateurs vont le mettre en cache.
Exemple d'utilisation: URL déplacée de/register-form.htmlàsignup-form.html.
La méthode passera à GET, conformément à la RFC 7231: "Pour des raisons historiques, un agent d'utilisateur PEUT changer la méthode de requête de POST à GET pour la requête suivante." - 302: redirection temporaire. À utiliser uniquement avec les clients HTTP/1.0. Ce code d’état ne doit pas changer la méthode, mais les navigateurs l’ont néanmoins fait. Le RFC indique: "De nombreux agents utilisateurs antérieurs à HTTP/1.1 ne comprennent pas [303]. Lorsque l'interopérabilité avec de tels clients est une préoccupation, le code d'état 302 peut être utilisé à la place, car la plupart des agents d'utilisateur réagissent à une réponse 302 comme décrit ici. pour 303. " Bien entendu, certains clients peuvent l'implémenter conformément à la spécification. Par conséquent, si l'interopérabilité avec de tels clients anciens n'est pas un problème, 303 est préférable pour des résultats cohérents.
- 303: redirection temporaire, modification de la méthode en GET.
Exemple d'utilisation: si le navigateur a envoyé POST à/register.php, chargez maintenant (GET)/success.html. - 307: redirection temporaire, répétant la requête à l'identique.
Exemple d'utilisation: si le navigateur a envoyé un POST à/register.php, cela lui dit de rétablir le POST à/signup.php. - 308: redirection permanente répétant la requête à l'identique. Où 307 est le pendant "pas de changement de méthode" de 303, le statut 308 est le "pas de changement de méthode" "contrepartie de 301.
RFC 7231 (de 2014) est très lisible et pas trop bavard. Si vous voulez connaître la réponse exacte, c'est une lecture recommandée. D'autres réponses utilisent la RFC 2616 de 1999, mais rien n'a changé.
RFC 7238 spécifie le statut 308. C'est considéré comme expérimental, mais c'était déjà supporté par tous les principaux navigateurs en 2016.
De plus, pour les administrateurs de serveur, il peut être important de noter que les navigateurs peuvent présenter une invite à l'utilisateur si vous utilisez la redirection 307.
Par exemple, *, Firefox et Opera demanderaient à l'utilisateur l'autorisation de rediriger les messages, alors que Chrome, IE et Safari effectueraient la redirection de manière transparente.
* par Bulletproof SSL et TLS (page 192).
Dans certains cas d'utilisation, un attaquant pourrait abuser des redirections 307 pour connaître les informations d'identification de la victime.
Des informations complémentaires sont disponibles dans , section 3.1 de Analyse de sécurité formelle complète de OAuth 2. .
Les auteurs du document ci-dessus suggèrent ce qui suit:
Correction. Contrairement à la formulation actuelle du standard OAuth, la méthode exacte de la redirection n'est pas un détail d'implémentation, mais elle est essentielle pour la sécurité de OAuth. Dans le standard HTTP ( RFC 7231 ), seule la redirection 303 est définie sans ambiguïté pour supprimer le corps d'une requête HTTP POST. Tous les autres codes d'état de redirection HTTP, y compris le code 302 le plus utilisé, permettent au navigateur de conserver la demande POST et les données du formulaire. En pratique, les navigateurs réécrivent généralement dans une demande GET, supprimant ainsi les données du formulaire, à l'exception des redirections 307. Par conséquent, la norme OAuth devrait nécessiter des redirections 303 pour les étapes mentionnées ci-dessus afin de résoudre ce problème.