http - telefonia - route header sip
¿Cuál es la diferencia entre un 302 y un 307 redirigir? (6)
¿Cuál es la diferencia entre una respuesta HTTP 302 FOUND y una 307 TEMPORARY REDIRECT HTTP?
La especificación W3 parece indicar que ambos se usan para redireccionamientos temporales, y ninguno puede almacenarse en caché a menos que la respuesta lo permita específicamente.
307 surgió porque los agentes de usuario adoptaron como comportamiento de facto las 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 : solo un 303 debería provocar que un POST se convierta en un GET. Los agentes de usuario deben (pero no deben) seguir con el 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 el cliente no debe realizar un cambio de método al seguir el encabezado de respuesta de Ubicación.
Además, para los administradores del servidor, puede ser importante tener en cuenta que los navegadores pueden presentar un aviso al usuario si usa la redirección 307.
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.
* por Bulletproof SSL y TLS (página 192).
ESPERADO por 302: el redireccionamiento usa el mismo método de solicitud POST en NEW_URL
CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL
ACTUAL for 302, 303: redirecciona el método de solicitud de cambios 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)
ACTUAL para 307: el redireccionamiento usa 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.
Se puede encontrar más información en la sección 3.1 de Un análisis integral de seguridad formal de OAuth 2.0 .
Los autores del documento anterior sugieren lo siguiente:
Fijar. A diferencia de 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.
La diferencia se relaciona con la redirección de las POST , PUT y DELETE y cuáles son las expectativas del servidor para el comportamiento del agente de usuario ( RFC 2616 ):
Nota: RFC 1945 y RFC 2068 especifican que el cliente no puede cambiar el método en la solicitud redirigida. Sin embargo, la mayoría de las implementaciones de agente de usuario existentes tratan 302 como si fuera una respuesta 303, realizando un GET en el valor de campo Ubicación, independientemente del método de solicitud original. Los códigos de estado 303 y 307 se han agregado para los servidores que desean aclarar inequívocamente qué tipo de reacción se espera del cliente.
Además, lea el artículo de Wikipedia sobre los códigos de redireccionamiento 30x .
Un buen ejemplo de la 307 Internal Redirect en acción es cuando Google Chrome encuentra una llamada HTTP a un dominio que sabe que requiere una estricta seguridad de transporte.
El navegador redirige sin problemas, utilizando el mismo método que la llamada original.