Guía completa de los códigos de estado HTTP: serie 400
Cada código 4xx, qué lo provoca y cómo distinguir un error del cliente de un servidor mal configurado.
Los problemas con un cliente user-agent pueden ir desde solicitar recursos que ya no están disponibles (por escribir mal un URI) hasta la reacción del servidor ante peticiones que encajan con la firma de un ataque.
El más común es el 404. El 404 Not Found se devuelve cuando un cliente solicita un recurso que el servidor web no puede encontrar:
Repasemos los códigos de respuesta más comunes e interesantes de la serie 400 con algo más de detalle.
400 Bad Request
El 400 Bad Request es (normalmente) el resultado de un user-agent que envía en la petición algo que el servidor web no pudo procesar. Generemos un 400 Bad Request para entender qué puede provocar este error.
Vamos a la vieja escuela en Linux y usaremos una herramienta llamada netcat. Netcat puede usarse para enviar datos en bruto a través de sockets. Al fin y al cabo, las peticiones HTTP/1.1 son exactamente eso: texto en bruto.
Primero, enviemos una petición HEAD legítima a google:
Forcemos un 400 Bad Request:
image: src /blog/wp-content/uploads/2017/12/3CEEAuo-e1513087453173.jpg (unchanged); alt: Petición incorrecta forzada que genera un 400
Enviamos a propósito una petición que el servidor no podía entender. Veamos el método de petición utilizado:
$ nc www.google.com 80 BAD / HTTP/1,1 Host: www.google.comEl servidor web no pudo procesar el método: BAD
Es poco probable que un navegador web moderno envíe peticiones malformadas como la anterior. Sin embargo, si usa una aplicación HTTP a medida, como un web scraper, es hora de depurar.
Estos pasos resuelven los errores 400 más comunes.
1. Compruebe la URL
Si hace clic en un enlace, es muy posible que el autor de la página cometiera una errata. Examine la URL completa, prestando especial atención a la ruta, el título del documento y la query string.
2. Borre todas las cookies y la cache
Borrar las cookies y la cache corrige muchos errores 400, y es también un buen primer paso para muchos otros códigos de estado 400.
- borre todas las cookies y el historial de navegación
- vuelva a intentar la petición
En Chrome, Edge y Firefox la opción está en los ajustes del navegador, bajo Privacidad, normalmente con el nombre «Borrar datos de navegación». Los nombres de los menús varían según la versión. Borrar solo las cookies del sitio afectado suele bastar.
Borrar todas las cookies y el historial garantiza que cualquier cosa en cache o corrupta (como las cookies) ha desaparecido. Esto a menudo corrige un 400 Bad Request.
3. Tamaño del archivo subido
El problema bien puede ser un script de backend, la subida de un archivo demasiado grande o de un archivo con un tipo de medio incorrecto.
- Si el 400 bad request aparece al subir un archivo, pruebe con un archivo más pequeño.
- Asegúrese de que el tipo de archivo es aceptado.
- Si sube una imagen, pruebe ambos formatos, jpeg y png.
- Si sube un documento, el texto plano y los formatos ofimáticos habituales suelen estar permitidos.
4. Cabeceras malformadas
Las cabeceras malformadas son un problema de bastante bajo nivel y bien podrían dejar a la propia aplicación web como responsable.
Las herramientas de desarrollo integradas en todo navegador moderno (la pestaña Network) nos permiten observar toda la transacción HTTP en busca de algo fuera de lo normal.
5. Actualice su navegador y desactive los plugins
Si su navegador está desactualizado, bien podría estar enviando cabeceras y peticiones anticuadas.
Además, pruebe a quitar o desactivar todos los plugins y extensiones. Probar la misma petición en otro navegador también puede ayudar a aislar el problema.
6. Pruebe a cerrar la sesión
Si usa una aplicación web con autenticación de usuarios y sesiones, pruebe a cerrar la sesión y después borrar la cache del navegador.
(hr)
401 Unauthorized
El 401 Unauthorized se devuelve cuando un servidor web solicita credenciales para un documento protegido.
403 Forbidden
El 403 Forbidden suele ser una de cuatro cosas:
- no se permiten los listados de directorio
- el usuario autenticado actual no tiene permisos suficientes
- el proceso del servidor web tiene permisos insuficientes
- la dirección solicitante ha sido bloqueada
Listado de directorio no permitido
Aquí el servidor web no permite listados de directorio a usuarios no autenticados. La solución más sencilla es poner un archivo index en el directorio. De lo contrario, los listados de directorio para usuarios no autenticados tendrán que configurarse de forma explícita.
El usuario autenticado no tiene permisos
El mejor método en esta situación es crear un grupo para todos los usuarios que necesitan acceso a un recurso. Dé a ese grupo los permisos necesarios a nivel de sistema de archivos. Después añada al grupo los usuarios permitidos.
El proceso del servidor web no tiene permisos suficientes
image: src /blog/wp-content/uploads/2017/12/XSkGl4h-e1513087253567.jpg (unchanged); alt: Acceso denegado
No podemos acceder a la página test.php en el webroot en /var/www/html. En RHEL y sus derivados (Oracle Linux, AlmaLinux, Rocky Linux) hay dos cosas que comprobar: los permisos de archivo clásicos y el contexto SELinux.
Primero, compruebe propiedad y permisos:
# ls -ld /var/www/html/ drwx------. 3 root root 4096 Nov 24 03:47 /var/www/html/El directorio pertenece al usuario root y al grupo root sin acceso para nadie más, así que el proceso del servidor web (usuario apache para Apache httpd, nginx para nginx) no puede leerlo. Dé al grupo del servidor web permiso de lectura, sin escritura:
# chgrp -R apache /var/www/html # chmod 750 /var/www/html # chmod 640 /var/www/html/test.php # ls -ld /var/www/html/ drwxr-x---. 3 root apache 4096 Nov 24 03:47 /var/www/html/ # ls -l /var/www/html/test.php -rw-r-----. 1 root apache 91 Nov 16 06:52 /var/www/html/test.phpSegundo, compruebe el contexto SELinux. Los archivos movidos al webroot desde otro sitio conservan su etiqueta antigua, y entonces SELinux bloquea al servidor web incluso cuando los permisos son correctos:
# ls -Z /var/www/html/test.php # restorecon -Rv /var/www/htmlEl contenido bajo /var/www/html debe llevar el tipo httpd_sys_content_t. Corrija la etiqueta con restorecon. Nunca desactive SELinux para hacer desaparecer un 403.
Como buena práctica de seguridad, el grupo del servidor web no debe tener permisos de escritura sobre archivos y carpetas. Donde un sistema de gestión de contenidos necesite escribir (una carpeta de uploads, por ejemplo), conceda permiso de escritura solo a esa carpeta, y en RHEL asígnele el tipo SELinux httpd_sys_rw_content_t.
Denegar permisos de escritura sobre archivos y carpetas puede aportar una capa adicional de seguridad en caso de que un atacante aproveche un fallo de la aplicación web para modificar contenido, borrar archivos o añadir archivos.
En un entorno de staging, ponga a los desarrolladores en el grupo del servidor web y dé a ese grupo permiso de escritura. Mantenga la producción en solo lectura.
Otro escenario habitual para un estado 403 Forbidden puede ser una dirección IP o un rango de IP bloqueado en un archivo .htaccess por el administrador del servidor.
404 Not Found
El 404 Not Found significa que el servidor web no pudo encontrar un recurso solicitado. Cuando encuentra un error 404 puede hacer varias cosas:
- compruebe la ortografía del host, el dominio, la ruta y el documento
- compruebe mayúsculas y minúsculas en el archivo y la ruta. Los servidores web en Linux y Unix (salvo que se configuren de otro modo) suelen distinguir mayúsculas de minúsculas, y la tradición es usar todo en minúsculas.
- use Google para encontrar una URL alternativa al recurso
- pruebe una copia archivada de la página en la Wayback Machine de Internet Archive
Uso de operadores avanzados de búsqueda de Google
image: src /blog/wp-content/uploads/2017/12/KbnaNqB-e1513087331180.jpg (unchanged); alt: Google: encontrar todos los archivos PDF
Una consulta como la anterior, con operadores como site: y filetype:, a menudo encuentra un documento cuyo enlace antiguo ahora devuelve 404.
Si la página ha sido retirada, la Wayback Machine de Internet Archive puede conservar todavía una copia anterior.
405 Method Not Allowed
Un 405 Method Not Allowed aparece cuando se intenta un método de petición que el servidor web no permite.
406 Not Acceptable
El 406 Not Acceptable se devuelve cuando el servidor no puede proporcionar el recurso en ninguno de los tipos de contenido, codificaciones, idiomas o juegos de caracteres que el cliente dice aceptar.
Para resolver un 406, mire las cabeceras de la petición en las herramientas de desarrollo de su navegador (pestaña Network).
Los valores de cabecera enviados por el cliente que conviene revisar incluyen:
- Accept
- Accept-Charset
- Accept-Encoding
- Accept-Language
Los navegadores modernos rara vez lo provocan. Si el suyo lo hace, pruebe a actualizarlo a una versión más reciente.
407 Proxy Authentication Required
El 407 Proxy Authentication Required normalmente significa que el user-agent debe proporcionar credenciales para acceder a un servidor proxy.
image: src /blog/wp-content/uploads/2017/12/GpVOCul.jpg (unchanged); alt: Proporcionar credenciales de proxy en Linux
408 Request Timeout
El 408 significa que el servidor esperó demasiado a que el cliente terminara de enviar su petición. Normalmente apunta a una conexión lenta o inestable del cliente, más que a un problema del servidor.
429 Too Many Requests
El 429 normalmente significa que se ha activado rate limiting en el servidor. El rate limiting solo permite un número determinado de peticiones en un intervalo de tiempo establecido.
Cuando reciba 429 Too Many Requests, reduzca el ritmo. El servidor puede enviar una cabecera Retry-After que indica cuánto esperar antes de volver a intentarlo. Los clientes y scripts bien educados la respetan y se retiran.
451 Unavailable for Legal Reasons
El 451 se devuelve cuando el servidor está legalmente obligado a bloquear el acceso a un recurso, por ejemplo tras una orden judicial.
Del archivo del blog de EuroVPS, publicado por primera vez el 12 de diciembre de 2017.
Todas las notas de campo