¿Cuál es la diferencia entre una respuesta HTTP 302 FOUND y 307 TEMPORARY REDIRECT?¿Cuál es la diferencia entre un 302 y un 307 redirigir?
The W3 spec parece indicar que ambos se usan para redireccionamientos temporales, y ninguno se puede almacenar en caché a menos que la respuesta lo permita específicamente.
Las preocupaciones de diferencia redirigir POST, PUT y DELETE solicitudes y cuáles son las expectativas del servidor son para el comportamiento del agente de usuario (RFC 2616):
Nota: RFC 1945 y RFC 2068 especifica que el cliente es no permitido cambiar el método en la solicitud redirigida . Sin embargo, la mayoría de las implementaciones de agentes de usuario existentes tratan 302 como si fuera una respuesta 303, realizando un GET en el campo de ubicación-valor independientemente del método de solicitud original . Los códigos de estado 303 y 307 se han agregado para los servidores que desean para dejar inequívocamente claro qué tipo de reacción se espera del cliente del cliente .
Además, lea el artículo de Wikipedia sobre el 30x redirection codes.
307 se produjo porque los agentes de usuario adoptaron como de facto el comportamiento para tomar solicitudes POST que reciben una respuesta 302 y envían una solicitud GET al encabezado de respuesta de Ubicación.
Ese es el comportamiento incorrecto — solamente un 303 debería causar un POST se convierta en un GET. Los agentes de usuario deben (pero no deben) apegarse al método POST al solicitar la nueva URL si la solicitud POST original devolvió un 302.
307 se introdujo para permitir a los servidores dejar claro al agente de usuario que un cambio de método debe no ser realizado por el cliente al seguir el encabezado de respuesta de Ubicación.
¿Algún ejemplo de agentes de usuario que responden incorrectamente? ¿Es generalmente un porcentaje muy pequeño de visitantes? – LamonteCristo
@ makerofthings7 Todos los navegadores manejan '302' incorrectamente. Chrome 30, IE10. Se convirtió en la implementación * de facto * incorrecta; eso no se puede cambiar porque muchos sitios web emiten erróneamente el número 302. De hecho ASP.net MVC emite incorrectamente 302, * dependiendo * del hecho de que los navegadores lo manejen incorrectamente. –
@IanBoyd Los marcos de razón solo lo hacen porque '303' también se introdujo con' 307' en la especificación HTTP 1.1 y, por lo tanto, permite la compatibilidad con agentes de usuario HTTP 1.0. Por supuesto, la verdadera pregunta es, ¿deberíamos seguir manejando los agentes de usuario de HTTP 1.0 ahora? – ewanm89
Un buen ejemplo del 307 Internal Redirect en acción es cuando Google Chrome encuentra una llamada HTTP a un dominio que sabe que requiere Seguridad de transporte estricta.
El navegador redirige sin problemas, utilizando el mismo método que la llamada original.
¿Sabes cuándo Google implementó esta función? – Tijme
Lo siento, no lo hago. –
Sí, aquí es donde estoy viendo que sucede - nuestro servidor no está enviando eso - en cromo devtools parece que es, pero es solo Chrome haciendo la redirección porque tenemos un encabezado de Seguridad de transporte estricto –
Además, para los administradores del servidor, puede ser importante tener en cuenta que los navegadores pueden presentar un mensaje para el usuario si utiliza 307 de redireccionamiento.
Por ejemplo *, Firefox y Opera le pedirían permiso al usuario para redirigir, mientras que Chrome, IE y Safari harían la redirección de forma transparente.
* según Bulletproof SSL and TLS (página 192).
Eso solo es cierto para solicitudes inseguras, como POST. –
esperado para 302: redirect utiliza misma petición método POST en NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL
real de 302, 303: redirigen cambios solicitud de método de POST a GET en 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)
real para 307 : el redireccionamiento utiliza el mismo método de solicitud POST en NEW_URL
CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL
En algunos casos de uso, un atacante podría abusar de 307 redireccionamientos para conocer las credenciales de la víctima.
Más información se puede encontrar en sección 3.1 de A Comprehensive Formal Security Analysis of OAuth 2.0.
Los autores del artículo anterior sugieren lo siguiente:
Fix. Contrariamente a la redacción actual en el estándar OAuth, el método exacto de la redirección no es un detalle de implementación, sino esencial para la seguridad de OAuth. En el estándar HTTP (RFC 7231), solo se define inequívocamente el redireccionamiento 303 para eliminar el cuerpo de una solicitud HTTP POST. Todos los demás códigos de estado de redireccionamiento HTTP, incluido el 302 más comúnmente usado, dejan al navegador la opción de conservar la solicitud POST y los datos del formulario. En la práctica, los navegadores normalmente reescriben a una solicitud GET, con lo que descartan los datos del formulario, excepto para los redireccionamientos 307. Por lo tanto, el estándar OAuth debe requerir 303 redirecciones para los pasos mencionados anteriormente para solucionar este problema.
Por lo tanto, desde una perspectiva de analizador/agente/navegador, podemos simplemente tratar 302 y 307 como idénticos ¿no? (¿El mismo fragmento de código ** exacto se puede usar para manejar ambos casos sin mayor distinción?) – Pacerier
No, puede tratar 302 y 303 como idénticos, pero 307 es diferente. –
@kkhugs, de ninguna manera, se requiere un navegador 1.0 para hacer el get-302 de la misma manera que get-307 se hace en 1.1 navegadores. Se requiere un navegador 1.0 para hacer post-302 de la misma forma que lo hace get-302, excepto que primero debe requerir una confirmación de usuario para continuar, y el método debe ser post. – Pacerier