Quelle est la différence entre une redirection 302 et 307?

Quelle est la différence entre une réponse HTTP 302 FOUNDet une 307 TEMPORARY REDIRECTréponse HTTP?

La spécification W3 semble indiquer qu'elles sont toutes deux utilisées pour des redirections temporaires, et aucune ne peut être mise en cache sauf si la réponse le permet spécifiquement.

Les préoccupations de différence redirigeant POST, PUTet les DELETEdemandes et les attentes du serveur sont pour le 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 utilisateur existantes traitent 302 comme s'il s'agissait d'une réponse 303, effectuant un GET sur la valeur de champ Location quelle que soit la méthode de demande d'origine. Les codes d'état 303 et 307 ont été ajoutés pour les serveurs qui souhaitent clarifier sans ambiguïté le type de réaction attendu du client.

Lisez également l'article Wikipedia sur les codes de redirection 30x .

307 est dû au fait que les agents utilisateurs ont adopté un comportement de facto pour accepter les demandes POST qui reçoivent une réponse 302 et envoyer une demande GET à l'en-tête de réponse Emplacement.

C'est le comportement incorrect - seul un 303 devrait faire en sorte qu'un POST se transforme en GET. Les agents utilisateurs doivent (mais ne respectent pas) la méthode POST lors de la demande de la nouvelle URL si la demande POST d'origine a renvoyé un 302.

307 a été introduit pour permettre aux serveurs d'indiquer clairement à l'agent utilisateur qu'un changement de méthode ne doit pas être effectué par le client lorsqu'il suit l'en-tête de réponse Emplacement.

Un bon exemple de l' 307 Internal Redirectaction est lorsque Google Chrome rencontre un appel HTTP vers un domaine qu'il sait 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.

• 301: redirection permanente: l'URL est ancienne et doit être remplacée. Les navigateurs mettront ceci en cache.
  Exemple d'utilisation: URL déplacée de /register-form.htmlvers signup-form.html.
  La méthode passera à GET, conformément à la RFC 7231: "Pour des raisons historiques, un agent utilisateur PEUT changer la méthode de demande de POST à ​​GET pour la demande suivante."
• 302: redirection temporaire. Utiliser uniquement pour les clients HTTP / 1.0. Ce code d'état ne devrait pas changer la méthode, mais les navigateurs l'ont quand même fait. Le RFC dit: "De nombreux agents utilisateurs antérieurs à HTTP / 1.1 ne comprennent pas [303]. Lorsque l'interopérabilité avec de tels clients est un problème, le code d'état 302 peut être utilisé à la place, car la plupart des agents utilisateurs réagissent à une réponse 302 comme décrit ici pour 303. " Bien sûr, certains clients peuvent l'implémenter selon les spécifications, donc si l'interopérabilité avec de tels anciens clients n'est pas une préoccupation réelle, 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étition identique de la demande.
  Exemple d'utilisation: si le navigateur a envoyé un POST à /register.php, cela lui indique de refaire le POST à /signup.php.
• 308: redirection permanente, répétition identique de la requête. Lorsque 307 est la contrepartie "pas de changement de méthode" de 303, ce statut 308 est la contrepartie "pas de changement de méthode" de 301.

La RFC 7231 (de 2014) est très lisible et pas trop verbeuse. Si vous voulez connaître la réponse exacte, c'est une lecture recommandée. Certaines autres réponses utilisent la RFC 2616 de 1999, mais rien n'a changé.

La RFC 7238 spécifie l'état 308. Il est considéré comme expérimental, mais il était déjà pris en charge par tous les principaux navigateurs en 2016.

ATTENDU pour 302: la redirection utilise la même méthode de demande POST sur NEW_URL

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

ACTUAL pour 302, 303: rediriger la méthode de demande de changement de POST vers 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

302 est une redirection temporaire, qui est générée par le serveur tandis que 307 est une réponse de redirection interne générée par le navigateur. La redirection interne signifie que la redirection est effectuée automatiquement par le navigateur en interne, fondamentalement, le navigateur modifie l'URL entrée de http à https dans la demande get par lui-même avant de faire la demande, de sorte que la demande de connexion non sécurisée n'est jamais effectuée sur Internet. Le fait que le navigateur modifie ou non l'URL en https dépend de la liste de préchargement hsts préinstallée avec le navigateur. Vous pouvez également ajouter n'importe quel site prenant en charge https à la liste en entrant le domaine dans la liste de préchargement hsts de votre propre navigateur qui se trouve sur chrome: //net-internals/#hsts.Une autre chose que les domaines de sites Web peuvent être ajoutés par leurs propriétaires pour précharger la liste en remplissant le formulaire sur https://hstspreload.org/afin qu'il soit préinstallé dans les navigateurs pour chaque utilisateur, même si je mentionne que vous pouvez également le faire pour vous-même.

Je m'explique avec un exemple:
j'ai fait une demande get à http://www.pentesteracademy.com qui ne prend en charge que https et je n'ai pas ce domaine dans ma liste de préchargement hsts sur mon navigateur car le propriétaire du site ne s'est pas enregistré pour cela à venir avec une liste de préchargement hsts préinstallée. La demande GET pour une version non sécurisée du site est redirigée vers une version sécurisée (voir l'en-tête http nommé emplacement pour cela en réponse dans l'image ci-dessus). Maintenant, j'ajoute le site à ma propre liste de préchargement du navigateur en ajoutant son domaine sous la forme Ajouter un domaine hsts sur chrome: // net-internals / # hsts, ce qui modifie ma liste de préchargement personnelle sur mon navigateur chrome.Veillez à sélectionner les sous-domaines pour Option STS là-bas. Voyons maintenant la demande et la réponse pour le même site Web après l'avoir ajouté à la liste de préchargement hsts.




vous pouvez voir la redirection interne 307 dans les en-têtes de réponse, en fait cette réponse est générée par votre navigateur et non par le serveur.
La liste de préchargement HSTS peut également empêcher les utilisateurs d'accéder à la version non sécurisée du site, car la redirection 302 est sujette aux attaques mitm.
J'espère que je vous ai un peu aidé à mieux comprendre les redirections.

À l'origine, il y avait juste 302

| Response               | What browsers should do   |
|------------------------|---------------------------|
| 302 Found              | Redo request with new url |

L'idée est que:

• si vous faisiez un GETà un endroit, vous referiez votre GETà la nouvelle URL
• si vous faisiez un POSTà un endroit, vous referiez votre POSTà la nouvelle URL
• si vous faisiez un PUTà un endroit, vous referiez votre PUTà la nouvelle URL
• si vous faisiez un DELETEà un endroit, vous referiez votre DELETEà la nouvelle URL
• etc

Malheureusement, tous les navigateurs l'ont mal fait. Lors de l'obtention d'un 302, ils basculeraient toujours vers GETla nouvelle URL, plutôt que de réessayer la demande avec le même verbe ( par exemple , POST):

• La mosaïque a mal fait
• Netscape a copié les bogues dans Mosaic; alors ils se sont trompés
• Internet Explorer a copié les bogues dans Netscape; alors ils se sont trompés

C'est devenu de facto faux.

Tous les navigateurs se sont 302trompés. Ainsi 303et 307ont été créés.

| Réponse | Ce que les navigateurs doivent faire | Ce que les navigateurs font réellement | | ------------------------ | ------------------------ --- | --------------------------- | | 302 trouvés | Refaire la demande avec une nouvelle URL | OBTENIR avec une nouvelle URL | | 303 Voir autre | OBTENIR avec une nouvelle URL | OBTENIR avec une nouvelle URL | | 307 Redirection temporaire | Refaire la demande avec une nouvelle URL | Refaire la demande avec une nouvelle URL |

Sous forme de graphique

Les 5 différents types de redirections:

╔═══════════╤════════════════════════════════════════════════╗
║           │                Switch to GET?                  ║
║ Temporary │          No            │         Yes           ║
╠═══════════╪════════════════════════╪═══════════════════════╣
║ No        │ 308 Permanent Redirect │ 301 Moved Permanently ║
╟───────────┼────────────────────────┼───────────────────────╢
║ Yes       │ 307 Temporary Redirect │ 303 See Other         ║
║           │ 302 Found (intended)   │ 302 Found (actual)    ║
╚═══════════╧════════════════════════╧═══════════════════════╝

Alternativement:

| Response                 | Switch to get? | Temporary? |
|--------------------------|----------------|------------|
| 301 Moved Permanently    | No             | No         |
| 302 Found (intended)     | No             | Yes        |
| 302 Found (actual)       | Yes            | Yes        |
| 303 See Other            | Yes            | Yes        |
| 307 Temporary Redirect   | No             | Yes        |
| 308 Permanent Redirect   | No             | No         |

En outre, 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, tandis que Chrome, IE et Safari feraient la redirection de manière transparente.

_{* selon SSL et TLS Bulletproof (page 192).}

Dans certains cas d'utilisation, 307 redirections peuvent être utilisées abusivement par un attaquant pour connaître les informations d'identification de la victime.

Pour plus d'informations, reportez-vous à la section 3.1 d' une analyse de sécurité formelle complète d'OAuth 2.0 .

Les auteurs de l'article ci-dessus suggèrent ce qui suit:

Réparer. Contrairement à la formulation actuelle de la norme OAuth, la méthode exacte de la redirection n'est pas un détail d'implémentation mais essentielle pour la sécurité d'OAuth. Dans la norme 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 couramment utilisé, laissent au navigateur l'option de conserver la demande POST et les données du formulaire. Dans la 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 doit exiger 303 redirections pour les étapes mentionnées ci-dessus afin de résoudre ce problème.