400 Bad Request

Uso

Cuando llega un error 400 Bad Request, corresponde al cliente examinar el cuerpo del mensaje para conocer más detalles sobre el fallo. El servidor devuelve suficiente información para que el cliente pueda corregir el problema. Entre los motivos habituales de una respuesta 400 Bad Request se encuentran:

Cuando se producen estos errores, el cliente puede intentar revisar de nuevo la URL, borrar las Cookies del navegador o comprimir un archivo demasiado grande antes de retransmitirlo.

Nota

Los errores 400 son errores del cliente (la solicitud está mal formada), mientras que los errores 500 son fallos del servidor (el servidor falló al procesar una solicitud válida). Un 400 no es temporal. Reintentar la misma solicitud produce el mismo error. El cliente debe corregir la solicitud antes de reintentar. Las extensiones del navegador o el adware que inyectan cabeceras mal formadas son una causa habitual de errores 400 inesperados. Desactivar las extensiones ayuda a diagnosticar el problema.

Impacto en SEO

Los motores de búsqueda como Google no indexan una URL que devuelve un estado 400. Las URL indexadas previamente que devuelven este código de estado se eliminan de los resultados de búsqueda. Las páginas que devuelven este código no consumen presupuesto de rastreo.

Ejemplo

El cliente solicita un recurso cuya ruta contiene caracteres de llave. Estos no son válidos en una URL, por lo que el servidor responde con 400 Bad Request.

Solicitud

GET /index{15}.html HTTP/1.1
Host: example.com

Respuesta

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 131

<html>
  <head>
    <title>Malformed URL</title>
  </head>
  <body>
    <p>Invalid characters in HTTP request</p>
  </body>
</html>

Cómo solucionarlo

Un 400 Bad Request significa que el servidor rechazó la solicitud por un problema de formato del lado del cliente.

Revise la URL en busca de errores de codificación. Los caracteres especiales como llaves, espacios o caracteres no ASCII necesitan codificación porcentual. Inspeccione la ruta completa de la solicitud y la cadena de consulta. Pase la URL por un validador para detectar secuencias de bytes ilegales.

Valide las cabeceras de la solicitud. Una cabecera Host mal formada, una cabecera Cookie demasiado grande o la ausencia de una cabecera obligatoria provocan este error. Compare las cabeceras con la especificación de la API. Use las herramientas de desarrollo del navegador (pestaña Network) o curl -v para inspeccionar las cabeceras en bruto enviadas con la solicitud.

Inspeccione el cuerpo de la solicitud en busca de errores de sintaxis. Un JSON inválido, una codificación de formulario defectuosa o una discrepancia entre la cabecera Content-Type y el formato real del cuerpo provocan el rechazo. Valide las cargas útiles JSON con un linter antes de enviarlas.

Borre la caché y las Cookies del navegador. Las Cookies corruptas o caducadas producen cabeceras de solicitud mal formadas. Los valores de cookie grandes que superan los límites de búfer del servidor son un desencadenante frecuente. Borre los datos almacenados y vuelva a intentarlo.

Verifique Content-Length frente al tamaño real del cuerpo. Una discrepancia entre el número de bytes declarado y el transmitido da lugar a una respuesta de solicitud incorrecta.

Revise los límites de tamaño del lado del servidor. nginx rechaza con un 400 las cabeceras demasiado grandes cuando superan el búfer configurado por large_client_header_buffers (valor predeterminado: 4 búferes de 8 KB). Aumente el valor en nginx.conf:

large_client_header_buffers 4 16k;

Apache aplica LimitRequestFieldSize (8190 bytes de forma predeterminada) y LimitRequestLine. Eleve estos valores en la configuración del servidor o del host virtual:

LimitRequestFieldSize 16384
LimitRequestLine 16384

Habilite el registro de depuración para identificar la causa exacta. nginx registra el motivo del rechazo en el nivel info. Establezca error_log en info y revise /var/log/nginx/error.log. Apache registra el nombre de la cabecera problemática en el registro de errores con LogLevel info.

Inspeccione el reenvío de cabeceras del proxy inverso. Cuando nginx o Apache actúa como proxy inverso, una cabecera Host, X-Forwarded-For o X-Real-IP mal configurada hace que el backend rechace la solicitud. Verifique que las directivas proxy_set_header pasan valores válidos.

Referencias de código

.NET

HttpStatusCode.BadRequest

Rust

http::StatusCode::BAD_REQUEST

Rails

:bad_request

Go

http.StatusBadRequest

Symfony

Response::HTTP_BAD_REQUEST

Python3.5+

http.HTTPStatus.BAD_REQUEST

Java

java.net.HttpURLConnection.HTTP_BAD_REQUEST

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_BAD_REQUEST

Angular

@angular/common/http/HttpStatusCode.BadRequest