Modos de encriptación AES explicados: por qué GCM supera a CBC en la mayoría de los casos (y en qué casos no) 2

Ha enviado un redirigido y fue del tipo incorrecto. Ahora cada navegador que lo recibió antes de usted lo ha almacenado permanentemente, y la única forma de solucionarlo es esperar el vencimiento del caché o pedir a los usuarios que eliminen su historial de navegación. Eso es un 301.

Esto no es un diccionario de códigos de estado — hay muchos de esos. Este es el guía que necesitas después de haber leído la tabla y aún así haber enviado el código incorrecto. Estamos revisando los que causan errores reales: cachés permanentes cuando se quería temporal, errores de autenticación que revelan información, respuestas de límite de velocidad que no se manejan correctamente, y timeouts de puente que apuntan a la capa equivocada.

301 vs 302 vs 307 vs 308: La Matriz de Redirecciones

El error que hace al menos una vez todo el mundo: usas 301 Moved Permanently mientras pruebas una reestructuración de URL. Funciona. Continúas. Luego reestructuras de nuevo. Y ahora un grupo de tus usuarios —cualquiera que visitó antes de la segunda modificación— son enviados a la antigua dirección de forma permanente, almacenada directamente en su navegador.

El 301 es permanente y se almacena de forma agresiva. Los navegadores establecen el tiempo de vida del redirigido almacenado en caché a casi infinito a menos que hayas establecido un Cache-Control encabezado. No hay forma programática de expirarlo desde el navegador del usuario. Si aún estás definiendo tu estructura de URL, usa 302.

El problema de la conservación del método es un caso diferente. Cuando un navegador sigue un 301 o 302, puede y en la práctica, casi siempre lo hace — reducir un POST a un GET en la redirección. Esto es técnicamente una violación del especificación original de HTTP/1.0, pero los navegadores la normalizaron hace mucho tiempo que el RFC 7231 la reconoce como comportamiento estándar. Si estás redirigiendo un POST —por ejemplo, después de una entrega de formulario— y esperas que el método se conserve, necesitas 307 o 308. Permanente?

Código	Conserva el método?	Usa para	No (POST → GET)
301	Sí	Redirecciones permanentes donde el GET es adecuado tras la redirección	Redirecciones temporales, banderas de características, pruebas A/B
302	No	Redirecciones permanentes donde el GET es adecuado tras la redirección	Redirecciones temporales donde se debe conservar el método
307	No	Sí	Redirecciones permanentes donde se debe conservar el método
308	Sí	Sí	El soporte de 308 es sólido ahora —Chrome, Firefox, Safari y Edge lo manejan correctamente. La advertencia: algunos clientes antiguos de API y bibliotecas HTTP aún no siguen correctamente el 308, por lo que si estás redirigiendo tráfico máquina a máquina y no controlas ni al cliente ni a su biblioteca HTTP, prueba explícitamente.

401 vs 403: Autenticación vs Autorización

401 significa “no has identificado tu cuenta”.

La especificación requiere que incluya un encabezado que indique al cliente cómo autenticarse. Es el código correcto cuando no hay sesión válida, no hay token o el token ha expirado. WWW-Authenticate 403 significa “sé quién eres y la respuesta es no”.

El usuario está autenticado pero carece de permisos. Devolver 403 en un token expirado es incorrecto — eso es un 401. Devolver 401 en una solicitud con permisos válidos pero insuficientes también es incorrecto, y peor aún, confunde tu depuración de autenticación: buscarás credenciales faltantes cuando el problema real es la asignación de roles. El argumento de seguridad para devolver

en lugar de 403 es real. Si tu API devuelve 403 en , has dicho claramente a cualquier atacante que el punto de acceso existe y que necesitaría privilegios más altos para acceder a él. Devolver 404 en su lugar no revela ninguna información sobre la existencia del recurso. Es una decisión: 403 es técnicamente correcto y más fácil de depurar; 404 es la opción segura para puntos de acceso sensibles donde la enumerabilidad importa. GET /admin/users429: El límite de velocidad es inútil sin Retry-After

Una respuesta 429 sin un

encabezado es una caja negra. El cliente sabe que ha sido limitado. No sabe si debe esperar 100ms o 24 horas. La mayoría de las implementaciones de clientes o intentan reintentar inmediatamente (atacando tu límite de velocidad) o abandonan por completo. Retry-After Toma ya sea un entero (segundos de espera) o una fecha HTTP (cuándo volver a intentar):

Retry-After los encabezados no están en ningún RFC — son una norma de facto proveniente de la API de GitHub que todos han copiado. Inclúyelos junto con

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1749254400

El X-RateLimit-* . El trio de Limit/Remaining/Reset informa al cliente de su situación antes de que llegue al límite, lo cual es más útil que simplemente saber que ha llegado al límite. Retry-AfterUna cosa que vale la pena destacar:

es también válido en respuestas 503, y significa lo mismo — “vuelve en este número de segundos”. Si tu servicio está temporalmente inactivo por una ventana de mantenimiento, envía un 503 con Retry-After en lugar de simplemente dejar las conexiones. Retry-After 503 vs 504: Dónde está el fallo?

Estos dos parecen similares pero apuntan a capas completamente diferentes de fallo, y mezclarlos te lleva a depurar en la dirección equivocada.

503 Servicio no disponible

significa que el servidor al que llegaste no puede manejar la solicitud en este momento — está sobrecargado, en modo de mantenimiento o una dependencia de backend está inactiva. El servidor mismo respondió; simplemente lo rechaza. 504 Timeout del Gateway

significa que un proxy o gateway (tu balanceador de carga, nginx, gateway de API, CDN) intentó alcanzar un servidor upstream y no recibió respuesta en el tiempo establecido. El servidor al que llegaste está vivo. Lo que está detrás de él no responde. En la práctica: si estás detrás de nginx y tu servidor de aplicación (Node, Rails, Django, etc.) se cae, obtienes 502 Bad Gateway — nginx recibió una respuesta, pero era incorrecta. Si el servidor de aplicación deja de responder completamente, obtienes 504. Si retornas un error intencional desde la capa de aplicación, obtienes 503. La distinción importa al triage: 504 significa que debes investigar el servicio upstream, tu configuración de tiempo de espera y tu red. 503 significa que debes investigar la aplicación en sí.

422 vs 400: Los errores de validación tienen su propio código

400 Request malformado

se usa para solicitudes que el servidor no puede parsear — JSON malformado, sintaxis incorrecta en la cadena de consulta, cabeceras requeridas faltantes. Es un problema estructural. 422 Entity no procesable

se usa para solicitudes que el servidor entendió pero no puede actuar porque los datos fallan en la validación — un rango de fechas donde el inicio es después del final, un campo de correo electrónico con una dirección inválida, un campo de cantidad que es negativo. La solicitud era sintácticamente correcta. Los aspectos semánticos eran incorrectos. La mayoría de las APIs combinan ambos en 400 y ocultan los detalles de validación en el cuerpo de la respuesta. Funciona, pero hace más difícil el manejo de errores en el cliente: los clientes deben analizar el cuerpo para saber si es un error de parseo o un error de validación. Usar 422 para errores de validación permite a los clientes basarse en el código de estado. Rails lo ha hecho correctamente desde siempre; el esquema JSON:API especifica 422 para errores de validación también.

Una nuance: 422 está definido en WebDAV (RFC 4918), no en la especificación principal de HTTP. En la práctica esto no importa — todos los clientes y servidores de HTTP lo manejan bien — pero ocasionalmente encontrarás un pedante que insiste en usar 400 en su lugar. No están completamente equivocados. Pero 422 es más específico y ampliamente comprendido.

204 vs 200 con cuerpo vacío: uno es correcto para DELETE

Cuando un DELETE es exitoso, la respuesta correcta es

204 No Content — no 200 con cuerpo vacío, ni 200 con 204 es la señal explícita de que “el éxito se produjo y no hay cuerpo de respuesta intencionalmente”. Un 200 con cuerpo vacío es técnicamente válido, pero es ambiguo — los clientes no saben si el cuerpo estaba planeado y se perdió, o si la ausencia es intencional. 204 elimina esa ambigüedad. {"success": true}.

La misma lógica se aplica a PUT y PATCH cuando no se devuelve el recurso actualizado. Si tu API devuelve el objeto actualizado tras un PATCH, usa 200. Si no, usa 204. No devuelvas 200 con un cuerpo vacío de

— eso es 204 vestido de traje. {} o null Una advertencia: 204 no debe incluir un cuerpo de mensaje

de acuerdo con el RFC 9110. Si devuelves 204 y accidentalmente incluyes un cuerpo (algunas frameworks te permiten), algunos clientes HTTP lo manejarán de forma gráfica, otros no. Elimina el cuerpo en tu manejador de respuesta, no solo en tu intención. Referencia rápida: Los códigos que realmente te pican y por qué Error común

Solución

Código	Significado	Redirección permanente	Usar durante pruebas — ahora está almacenada para siempre
301	Usa 302 hasta que la redirección se confirme permanente	Redirección temporal	Un POST se reduce a GET al seguirse
302	Usa 307 si se debe conservar el método	Redirección temporal (segura para el método)	Confundida con 302
307	Usa cuando se redirige un POST/PUT/PATCH temporalmente	Redirección permanente (segura para el método)	Omitida en favor de 301 por hábito
308	Usa en lugar de 301 cuando el método importa	Error de solicitud (error de parseo)	Usado para errores de validación también
400	Usa 422 para fallos de validación semánticos	No autenticado	Devuelto cuando el usuario carece de permisos (debería ser 403)
401	Devuelve 401 solo cuando faltan credenciales o han expirado	Devuelto en lugar de 404 para puntos de acceso sensibles	Considera 404 cuando ocultar la existencia del punto de acceso importa
403	Prohibido	Entidad no procesable	Combinada en 400
422	Usa para fallos de validación donde el cuerpo era parseable	Límite de velocidad alcanzado	Falta el encabezado Retry-After
429	Incluye siempre Retry-After + X-RateLimit-* encabezados	Servicio no disponible	Confundido con 504
503	Usa cuando el servidor alcanzado no puede manejar la solicitud	Timeout del gateway	Confundido con 503
504	Investiga el servicio upstream, no el gateway	Sin contenido	Devuelve 200 con cuerpo vacío en su lugar
204	Usa 204 para DELETE/PUT/PATCH exitosos sin cuerpo de respuesta	Si necesitas buscar rápidamente cualquier código de estado mientras se depura,	IO Tools tiene una búsqueda de códigos de estado HTTP

que cubre el rango completo con descripciones y notas sobre cuándo usar cada uno. El patrón detrás de todos estos casos La mayoría de estos errores provienen del mismo lugar: tratar los códigos de estado como categorías sueltas (“4xx es error del cliente, 5xx es error del servidor, listo”) en lugar de como un protocolo con semánticas específicas. Las semánticas importan porque los clientes — navegadores, bibliotecas HTTP, CDNs, herramientas de monitoreo — realmente se basan en ellos. Un CDN no almacenará un 200 y un 204 de la misma manera. Un cliente HTTP no reintentará un 400 y un 503 con la misma lógica. Un navegador no almacenará un 302 y un 301 con el mismo TTL.

Usa el código correcto. La sobrecarga es cero. El beneficio de depuración cuando algo falla no lo es.

Códigos de estado HTTP que realmente te pican — 301 vs 302, 401 vs 403 y el campo de 5xx 2

Códigos de estado HTTP que realmente te pican — 301 vs 302, 401 vs 403 y el campo de 5xx 1

También te puede interesar