Búsqueda de Códigos HTTP Status

Códigos HTTP Status — Referencia Completa de 100 a 511

Cada respuesta HTTP de un servidor incluye un código de tres dígitos que indica al cliente qué pasó. Los códigos se agrupan en cinco categorías: 1xx (informativos), 2xx (éxito), 3xx (redirección), 4xx (error cliente) y 5xx (error servidor). Esta referencia lista los más de 60 códigos registrados con nombres, descripciones, casos de uso comunes y enlaces a los RFC que los definen. Filtra por categoría, busca por número o palabra clave, o copia cualquier código al portapapeles para documentación, reportes de bugs o mensajes de commit.

¿Cuál es la diferencia entre 401 Unauthorized y 403 Forbidden?

Los dos códigos parecen similares pero significan cosas distintas:

- **401 Unauthorized** — el cliente no se ha autenticado, o la autenticación falló. El arreglo es iniciar sesión o enviar un token válido. La respuesta debería incluir un header WWW-Authenticate diciéndole al cliente cómo. Confusamente, a pesar del nombre, 401 significa 'no autenticado'.

- **403 Forbidden** — el cliente está autenticado pero no tiene permiso para este recurso específico. Reintentar con las mismas credenciales no lo arreglará; el usuario simplemente carece de acceso.

Un patrón común en aplicaciones sensibles a la seguridad es devolver 404 Not Found en lugar de 403 para evitar revelar que un recurso restringido siquiera existe. Por ejemplo, GitHub devuelve 404 para repos privados a los que no tienes acceso, no 403.

¿Debería usar 301 o 308 para un redirect permanente?

Depende del método HTTP. Los dos códigos significan lo mismo semánticamente (ambos son redirects permanentes), pero se comportan distinto cuando la solicitud original era POST/PUT/DELETE:

- **301 Moved Permanently** — RFC 9110 permite explícitamente que los clientes cambien el método a GET al seguir un 301. Históricamente, la mayoría de navegadores siempre hacían esto, incluso para POST. Usa 301 solo para redirects GET.

- **308 Permanent Redirect** — preserva explícitamente el método original. POST sigue siendo POST, DELETE sigue siendo DELETE. Usa 308 cuando el redirect deba funcionar para endpoints API.

Para sitios web que mayormente redirigen GET (ej. HTTP → HTTPS, www → no-www), 301 está bien y tiene soporte ligeramente mejor en clientes antiguos. Para APIs y formularios, prefiere 308.

La misma distinción existe para redirects temporales: 302 (laxo) vs 307 (preserva método).

¿Cuándo es apropiado 422 Unprocessable Content?

422 es el código correcto cuando la sintaxis de la solicitud es válida (JSON bien formado, content-type correcto) pero el contenido *semántico* está mal. El ejemplo clásico es un formulario de registro donde:

- El JSON parsea correctamente → no es 400
- El campo email está presente → no es error de campo faltante
- Pero la dirección de email está mal formada (ej. 'not-an-email') → 422 Unprocessable Content

Vs. 400 Bad Request que debería reservarse para:

- JSON mal formado (error de parse)
- Campos requeridos faltantes
- Header content-type incorrecto

En la práctica, muchas APIs usan 400 para todo lo del lado cliente, y eso también es aceptable. La distinción importa cuando quieres dar a los clientes una forma programática de distinguir 'arregla tus datos' de 'arregla tu formato de solicitud'. GitHub, Stripe y la mayoría de APIs REST modernas usan 422 para errores de validación.

¿Cuál es el código correcto para rate limiting?

**429 Too Many Requests** es la respuesta canónica (RFC 6585). La respuesta debería incluir:

- Un header **Retry-After** — segundos (`Retry-After: 60`) o una fecha HTTP — diciéndole al cliente cuándo reintentar.
- Un cuerpo opcional explicando el límite. JSON como `{"error": "rate_limit_exceeded", "retry_after": 60}` es común.
- Un trío opcional de headers **X-RateLimit-Limit**, **X-RateLimit-Remaining**, **X-RateLimit-Reset** para que los clientes rastreen cuotas.

Para protección tipo DDoS donde quieres descartar la solicitud silenciosamente, devolver 503 Service Unavailable con un Retry-After largo a veces se usa como alternativa.

Evita usar 503 para rate-limiting normal porque le dice al cliente que el *servidor* está fallando, no el cliente. 429 es la señal correcta de 'estás enviando demasiado, baja el ritmo'.

¿Es real 418 'I'm a teapot'?

Sí, más o menos. El RFC 2324 define el HyperText Coffee Pot Control Protocol (HTCPCP), un RFC del Día de los Inocentes de 1998 que especificó protocolos para hacer café sobre HTTP. Cualquier intento de hacer café con una tetera devuelve 418 I'm a teapot.

El código está oficialmente registrado con IANA pero se reserva como broma. En 2017 hubo un empuje medio en serio para retirarlo de las librerías de servidor (Node.js lo eliminó brevemente); la comunidad presionó atrás y la mayoría de stacks lo mantuvieron.

Casos de uso reales para 418 son limitados:

- **Bromas del Día de los Inocentes** — algunos sitios devuelven 418 desde un endpoint /teapot.
- **Huevos de pascua** en documentación API.
- **Detección de scrapers automáticos** — algunos sitios devuelven 418 para patrones de tráfico sospechosos.

No uses 418 en producción para errores reales — los clientes no sabrán qué hacer con él.

¿Qué significa 503 y cómo difiere de 500?

**500 Internal Server Error** es un catch-all genérico: el servidor topó con una condición inesperada (un bug, una excepción no manejada) y no pudo completar la solicitud. La implicación es que reintentar inmediatamente probablemente no ayude — algo va mal del lado servidor.

**503 Service Unavailable** es más específico: el servicio está temporalmente caído, normalmente por sobrecarga, mantenimiento planeado o lag de autoscaling. La implicación es que reintentar más tarde (a menudo con el header **Retry-After** indicando cuándo) tendrá éxito.

Algunas sutilezas:

- Un load balancer devolviendo 503 significa que el upstream es inalcanzable. Mira los logs del LB.
- Una aplicación devolviendo 503 significa que está rechazando solicitudes intencionalmente (modo mantenimiento, circuit breaker disparado).
- 503 nunca debería ser devuelto por un crash de app — eso es territorio de 500.
- Cloudflare y otras CDNs tienen sus propios códigos 5xx (520, 521, 522, 523, 524, 525, 526, 527) para errores upstream específicos.

¿Por qué el rango 1xx se ve raramente en las herramientas?

Los códigos 1xx son intermedios — se envían *antes* de la respuesta final. La mayoría de herramientas (navegadores, curl, Postman) no los exponen porque cuando llega la respuesta final 2xx/3xx/4xx/5xx, el contexto 1xx ya se perdió.

Los tres que verás ocasionalmente:

- **100 Continue** — enviado cuando un cliente usa `Expect: 100-continue` para preguntar si el servidor aceptará una subida grande antes de enviar el cuerpo.
- **101 Switching Protocols** — enviado durante una actualización de protocolo, más comúnmente el handshake WebSocket.
- **103 Early Hints** — más nuevo (2017, RFC 8297). Permite al servidor enviar hints `Link: preload` antes de la respuesta final, para que el navegador empiece a descargar CSS, JS y fuentes en paralelo. Usado por Cloudflare y Fastly.

102 Processing existe (RFC 2518 para WebDAV) pero apenas se usa fuera de servidores WebDAV de nicho.

¿De dónde vienen estos códigos?

Los códigos HTTP status están definidos a lo largo de múltiples RFCs:

- **RFC 9110** (junio 2024) — la especificación actual de semántica HTTP, definiendo los códigos base 1xx, 2xx, 3xx, 4xx, 5xx. Reemplazó el RFC 7231 en 2024.
- **RFC 4918** — WebDAV (207 Multi-Status, 422 Unprocessable Content [ahora en 9110], 423 Locked, 424 Failed Dependency, 507 Insufficient Storage).
- **RFC 6585** — Códigos HTTP adicionales (428, 429, 431, 511).
- **RFC 7538** — 308 Permanent Redirect.
- **RFC 7725** — 451 Unavailable For Legal Reasons.
- **RFC 8297** — 103 Early Hints.
- **RFC 8470** — 425 Too Early (TLS 1.3).
- **RFC 2324** — 418 I'm a teapot (broma del Día de los Inocentes).
- **IANA HTTP Status Code Registry** — la lista autoritativa de todos los códigos registrados.

Cada tarjeta en esta referencia enlaza al RFC que define ese código de status, para que siempre puedas ir a la fuente autoritativa para casos límite.

Características Principales

• Todos los códigos HTTP status registrados en IANA (60+) cubriendo 100 a 511
• Descripciones detalladas para los 25 códigos más comunes (200, 301, 304, 401, 403, 404, 429, 500, 503, etc.)
• Búsqueda por número de código o palabra clave en nombres y descripciones
• Filtro por categoría: 1xx Informativo, 2xx Éxito, 3xx Redirección, 4xx Error Cliente, 5xx Error Servidor
• Indicadores de categoría codificados por color para reconocimiento visual instantáneo
• Enlaces directos al RFC definitorio de cada código (RFC 9110, RFC 6585, etc.)
• Botones de salto rápido para los cuatro códigos más buscados (200, 301, 404, 500)
• Copia cualquier código al portapapeles con un clic para reportes de bugs y documentación
• Ejemplos de casos de uso explicando cuándo es apropiado cada código
• Cubre adiciones modernas: 103 Early Hints, 308 Permanent Redirect, 425 Too Early, 451 Legal
• Incluye el 418 I'm a teapot del RFC 2324 para completar
• JavaScript puro — sin bibliotecas externas
• Funciona offline tras la primera carga
• Diseño de cuadrícula responsive para móvil y escritorio
• 100% del lado del cliente — la búsqueda no hace peticiones