Códigos 4xx explicados: qué significan de verdad los errores de cliente

Qué dice la clase 4xx

El RFC 9110 define la clase 4xx como "Client Error": el servidor cree que el cliente ha cometido un error. Eso cubre una petición de algo que no existe, una petición sin las credenciales que necesita, una petición que el servidor rechaza por motivos de política y una petición mal formada o demasiado grande.

Tres propiedades de la clase importan mientras depuras una:

• Un 4xx es una respuesta final para esa petición tal como se envió. Repetir la petición idéntica normalmente producirá el mismo código.
• El cuerpo de la respuesta está pensado como una explicación legible por humanos. Por eso existen las páginas de error personalizadas, y por eso una página 404 vacía es una oportunidad desperdiciada.
• Algunas respuestas 4xx se pueden cachear por defecto. El RFC 9111 incluye 404, 405, 410 y 414 entre los códigos que una caché puede guardar de forma heurística, así que un 404 equivocado puede sobrevivir al fallo que lo causó.

Los códigos 4xx que te encontrarás

• 400 Bad Request: la petición está mal formada y el servidor no puede interpretarla. Con frecuencia una cadena de consulta mal formada, una cabecera de cookie demasiado grande o un proxy roto delante de la aplicación.
• 401 Unauthorized: se requiere autenticación y falta o no es válida. El servidor tiene que enviar una cabecera WWW-Authenticate diciendo al cliente cómo autenticarse.
• 403 Forbidden: el servidor entendió la petición y la rechaza. Las credenciales no ayudarán, porque el rechazo es una decisión de política y no un fallo de autenticación.
• 404 Not Found: no existe ninguna representación actual en esa URL, o el servidor no admite que exista. Cubierto en detalle en la guía del 404.
• 405 Method Not Allowed: la URL existe pero no para ese método. El servidor tiene que listar los métodos que sí acepta en una cabecera Allow.
• 408 Request Timeout: el cliente tardó demasiado en enviar la petición. Distinto de un 504, donde el retraso está detrás del servidor.
• 410 Gone: el recurso existió y se eliminó deliberadamente, y se espera que sea permanente.
• 413 Content Too Large y 414 URI Too Long: la petición superó un límite configurado, normalmente un tope de subida o un límite de tamaño de cabecera.
• 429 Too Many Requests: se alcanzó un límite de tasa. Este en particular muerde a las configuraciones de monitorización.

Cuándo un 4xx es en realidad una mala configuración del servidor

La etiqueta de "error de cliente" trata de roles de protocolo, no de culpa. La mayoría de los códigos 4xx que aparecen en un sitio de producción sano están causados por algo de tu lado. Una regla de reescritura o de enrutamiento que ya no coincide convierte URLs válidas en 404 en todo un directorio, y la pista es un 404 en muchas URLs a la vez en lugar de en una sola. Una compilación que deja de generar un recurso con hash hace lo mismo a nivel de archivo: cada página pide un archivo que devuelve 404, así que la página se renderiza pero se ve rota.

Las capas de seguridad explican buena parte del resto. Una regla de WAF, un filtro de bots o un bloqueo geográfico pueden devolver 403 a tráfico real, y son fáciles de pasar por alto porque normalmente dejan pasar la IP de la oficina. Un cambio de autenticación que deja una página respondiendo 401 cuando debería ser pública es un 4xx causado enteramente por el servidor. Lo mismo un 400 o un 413 de un proxy inverso cuyo límite de cabecera o de cuerpo es menor que el de la aplicación, para una petición que la aplicación habría aceptado.

Cómo diagnosticar un 4xx en tu propio sitio

1. Lee primero el código exacto y las cabeceras. No juzgues por la página de error, que puede ser genérica:

   curl -sS -o /dev/null -D - https://example.com/broken-page

   Esto muestra la línea de estado más Allow, WWW-Authenticate, Retry-After y cualquier cabecera de identificación del servidor o la CDN.
2. Decide si es una URL o un patrón. Una sola URL señala un enlace o una página eliminada. Todo un prefijo de ruta señala el enrutamiento, los permisos o un despliegue.
3. Comprueba quién respondió. Compara la respuesta desde el borde de la CDN con la respuesta desde el origen. Un 403 que solo existe en el borde es una regla de WAF o de bots, no tu aplicación.
4. Prueba una identidad de cliente distinta. Un user agent distinto, una sesión sin autenticar o una red distinta pueden convertir el código de 403 a 200, lo que localiza el bloqueo de inmediato.
5. Lee la línea del registro del servidor para esa petición. Los registros del servidor web y de la aplicación anotan qué regla o manejador produjo el código. Este es el paso que normalmente termina la investigación.
6. Arregla, y luego purga las cachés. Como varios códigos 4xx se pueden cachear, una página corregida puede seguir sirviendo el error antiguo desde una CDN o una caché de navegador hasta que se invalide la entrada.

Encontrar las páginas 4xx que nunca visitas

Un 4xx no tumba un servidor, por lo que pasa desapercibido. El sitio carga, la página de inicio está bien, y una sección devuelve 404 o 403 para todo el mundo menos para ti. Una comprobación HTTP programada compara el código que recibe con el código que esperas, así que una página que empieza a responder 403 en lugar de 200 dispara una alerta en lugar de esperar a un ticket de soporte. También importa desde dónde se ejecuta la comprobación. HostTracker comprueba desde más de 300 puntos de control en 158 ciudades, así que un bloqueo geográfico o una regla de WAF regional aparece como una diferencia real entre ubicaciones en lugar de un misterio. Si el código que falla es 500, 502 o 503 en su lugar, la causa está del lado del servidor y la guía de la familia 5xx es el sitio por donde empezar.