El error HTTP 400 Bad Request: aprende a so­lu­cio­nar­lo

Navegar por Internet no siempre tra­n­s­cu­rre como debería, y de vez en cuando el navegador muestra un código de estado en lugar del contenido que se buscaba. En el es­ta­ble­ci­mie­n­to de la co­mu­ni­ca­ción entre el servidor web y el cliente (el navegador), se tra­n­s­mi­ten mensajes de estado y solo cuando surge un problema la ventana del navegador web muestra un mensaje de error más o menos críptico. El mensaje de error HTTP 400 indica que hay algo que no ha fu­n­cio­na­do bien en la petición del cliente. En el presente artículo te contamos cuál es el verdadero si­g­ni­fi­ca­do del error 400 Bad Request y qué puedes hacer para so­lu­cio­nar­lo.

Con los códigos de estado, un servidor web es capaz de devolver al cliente el estado actual de las so­li­ci­tu­des. Si el servidor entrega el mensaje 200 (no­r­ma­l­me­n­te im­pe­r­ce­p­ti­ble cuando se navega por Internet), esto indica que todo funciona bien, lo que significa que la solicitud se ha realizado con éxito y que se han tra­n­s­mi­ti­do los co­n­te­ni­dos deseados. Sin embargo, no ocurre lo mismo con los códigos de la clase 4XX y 5XX, que indican la presencia de di­fe­re­n­tes tipos de errores. Los códigos del 100 al 103 hacen re­fe­re­n­cia a procesos en fu­n­cio­na­mie­n­to y los relativos al 200 (200-208) a procesos fi­na­li­za­dos con éxito. Por lo general, estos pasan des­ape­r­ci­bi­dos para los usuarios de Internet del mismo modo que los errores de la clase 3XX (300-308), que indican que la co­mu­ni­ca­ción se ha llevado a cabo co­rre­c­ta­me­n­te pero el cliente ha de in­te­r­ve­nir yendo un paso más allá. En la mayoría de los casos se trata de re­di­re­c­cio­nes que el navegador realiza au­to­má­ti­ca­me­n­te y que los usuarios apenas perciben. Todo lo contrario ocurre con los mensajes de error: mientras que los del grupo 500 están re­la­cio­na­dos con los errores que tienen lugar del lado del servidor, los del grupo 400 se reducen a pe­ti­cio­nes in­co­rre­c­tas del lado del cliente. El más conocido es el error 404 Not Found, cuya causa suele ser una dirección URL in­co­rre­c­ta o co­n­te­ni­dos eli­mi­na­dos.   En el caso del error HTTP 400 no es fácil dilucidar por qué se ha producido, si bien bá­si­ca­me­n­te algo ha ido mal en la petición. El protocolo de Internet HTTP no se ha cumplido de manera correcta, al menos según el servidor web, por lo que la petición no puede pro­ce­sar­se. Como co­n­se­cue­n­cia, el servidor la ha in­te­r­pre­ta­do como errónea o dañina y ha impedido la entrega de la página. En este sentido, las causas del mensaje de error suelen estar, por lo general, re­la­cio­na­das con el navegador empleado o se pueden atribuir a un error por parte del usuario:

• Dirección URL in­co­rre­c­ta: al igual que el error 404, un error 400 Bad Request se produce cuando los usuarios in­tro­du­cen una dirección in­co­rre­c­ta y, por ejemplo, insertan ca­ra­c­te­res es­pe­cia­les ilícitos. 

• Cookies con errores: el error 400 también puede surgir cuando las cookies de un navegador están obsoletas o contienen errores.

• Registros DNS obsoletos: puede que la caché del DNS contenga archivos que remitan a di­re­c­cio­nes IP falsas.

• Archivos muy grandes: cuando se intenta cargar archivos muy grandes, el servidor puede negarse a ace­p­tar­los, lo que también es co­n­si­de­ra­do como un error HTTP 400.

• En­ca­be­za­dos muy largos: durante la co­mu­ni­ca­ción, el cliente y el servidor utilizan en­ca­be­za­dos en los que se define la petición y algunos se­r­vi­do­res web es­ta­ble­cen un límite mayor para la longitud de estos en­ca­be­za­dos.  

Con el error Bad Request 400 tampoco es sencillo deducir di­re­c­ta­me­n­te en qué punto de la co­mu­ni­ca­ción ha surgido el problema. En caso de usar un servidor web IIS 7.0, IIS 7.5 o IIS 8.0, se pueden extraer ciertos datos del código de estado:

• 400.1: de­s­ti­na­tion header inválido
• 400.2: depth header inválido
• 400.3: if header inválido
• 400.4: overwrite header inválido
• 400.5: translate header inválido
• 400.6: request body inválido
• 400.7: longitud del contenido inválida
• 400.8: timeout inválido
• 400.9: lock token inválido

El error 400 no solo aparece cuando se utiliza un navegador, sino que hay otros programas, como los clientes de correo ele­c­tró­ni­co, que también pueden recibir este código de estado a la hora de co­mu­ni­car­se con un servidor.

Como ocurre con la mayoría de códigos de estado que muestran un mensaje de error, en muchos casos es su­fi­cie­n­te con refrescar la página. Puede que el problema sea temporal si es la primera vez que el error aparece en una página que no­r­ma­l­me­n­te no suele presentar ningún fallo, pero si el error persiste una vez ac­tua­li­za­da la página, puede que la solución sea borrar la caché del navegador. Es posible también que el navegador web haya guardado una copia en el momento en el que ha aparecido el mensaje de error.

Dirección URL in­co­rre­c­ta

El siguiente paso para el análisis del problema debe ser revisar la dirección URL: en caso de que tú mismo hayas insertado la dirección en la línea del navegador, es re­co­me­n­da­ble que co­m­prue­bes que no haya ningún error or­to­grá­fi­co. Si has pinchado en un enlace, ahí mismo puedes comprobar la or­to­gra­fía o ir primero a la página principal y acceder desde ahí a la subpágina deseada.

Cookies con errores

El problema también puede deberse a la presencia de cookies obsoletas o que contengan errores. Para so­lu­cio­nar­lo se debe eliminar el registro co­rre­s­po­n­die­n­te en el navegador y cuando se vuelve a visitar la página, el software deposita una cookie nueva.

Registros DNS erróneos

Otra posible solución a la que se puede recurrir en caso de que aparezca el error 400 es la de eliminar la memoria caché del DNS. Cuando se navega por Internet, los nombres de dominio in­tro­du­ci­dos se traducen en di­re­c­cio­nes IP, pues solo de esta manera se puede es­ta­ble­cer la conexión en la World Wide Web. Para ello se tiene que realizar la re­so­lu­ción de nombres en el servidor de nombres y, para acortar el proceso, el ordenador en cuestión almacena te­m­po­ra­l­me­n­te en la caché DNS los datos re­co­pi­la­dos. Pero si el registro en la caché no se elimina au­to­má­ti­ca­me­n­te, la próxima vez que in­tro­du­z­cas el dominio en el navegador la re­so­lu­ción de nombres tendrá lugar di­re­c­ta­me­n­te desde la caché. Si la entrada está de­fe­c­tuo­sa o des­ac­tua­li­za­da aparecerá el mensaje “HTTP Bad Request”. Para eliminar la entrada de­fe­c­tuo­sa se debe borrar la caché DNS completa, lo que se puede lograr en Windows a través del símbolo del sistema in­tro­du­cie­n­do el siguiente comando:

                ipconfig /flushdns

En los sistemas Mac el comando depende de la versión del sistema operativo. Introduce el co­rre­s­po­n­die­n­te en el terminal:

• OS X 10.4 (Tiger): lookupd -flu­sh­ca­che
• OS X 10.5 (Leopard): ds­ca­cheu­til -flu­sh­ca­che
• OS X 10.6 (Snow Leopard): ds­ca­cheu­til - flu­sh­ca­che
• OS X 10.7 (Lion): sudo killall -HUP mD­N­S­Re­s­po­n­der
• OS X 10.8 (Mountain Lion): sudo killall -HUP mD­N­S­Re­s­po­n­der
• OS X 10.9 (Mavericks): ds­ca­cheu­til -flu­sh­ca­she; sudo killall -HUP mD­N­S­Re­s­po­n­der
• OS X 10.10 (Yosemite) (10.10.1 – 10.10.3): sudo di­s­co­ve­ru­til ud­n­s­fla­sh­ca­ches
• OS X 10.10 (Yosemite) (10.10.4+): sudo ds­ca­cheu­til -flu­sh­ca­che; sudo killall -HUP mD­N­S­Re­s­po­n­der
• OS X 10.11 (El Capitan): sudo killall -HUP mD­N­S­Re­s­po­n­der
• macOS 10.12 (Sierra): sudo killall -HUP mD­N­S­Re­s­po­n­der

Para we­b­ma­s­te­rs: ampliar los límites

Si eres un webmaster y hay visitas que se han quejado de la presencia del error HTTP code 400, puede ser de ayuda modificar los ajustes del servidor. Para que los usuarios no tengan que recibir este mensaje de error debido a un en­ca­be­za­do HTTP de gran tamaño, puedes ampliar el límite, pero teniendo en cuenta que con unos límites más amplios también puede aumentar el riesgo de recibir pe­ti­cio­nes con errores. La Internet En­gi­nee­ri­ng Task Force (IETF) aborda el código de error 400 en su do­cu­me­n­ta­ción sobre HTTP 1.1 y advierte del riesgo que suponen los límites amplios (smuggling attacks):

¿Quieres aumentar el límite pese a todo? Para ello cada servidor web tiene un método diferente. En el caso del IIS (con ASP.NET) modifica, por ejemplo, “ma­x­Re­que­stLe­n­g­th” y “ma­xA­llo­we­d­Co­n­te­ntLe­n­g­th”. En Apache puedes fijar los límites con “Li­mi­tRe­que­s­t­Fie­l­d­Si­ze”.

Toma de contacto

En ocasiones puede ocurrir que ninguna de las so­lu­cio­nes an­te­rio­res resuelve el problema. En ese caso se debe buscar otro tipo de ayuda. Para ello tienes dos po­si­bi­li­da­des de contacto en función de si el error 400 aparece en una página de­te­r­mi­na­da, en varias o en todas las páginas. Si el error solo se origina en una página de­te­r­mi­na­da y hasta ahora todos los intentos por so­l­ve­n­tar­lo han sido en vano, puedes ponerte en contacto con el webmaster de la página. Por otro lado, en aquellos casos en los que ya no puedas navegar por Internet de manera habitual, debido a la presencia pe­r­ma­ne­n­te del error code 400, debes co­mu­ni­car­te con tu proveedor de Internet, puesto que, aun si el problema no proviene realmente de dicho proveedor, el equipo de asi­s­te­n­cia técnica puede ayudarte a encontrar una solución.

En ambas si­tua­cio­nes se re­co­mie­n­da aportar a las personas de contacto la mayor cantidad de in­fo­r­ma­ción posible. Esto incluye, por un lado, todos los intentos rea­li­za­dos hasta la fecha para so­lu­cio­nar el problema y, por el otro, datos de interés sobre tu sistema como:

• el sistema operativo y el navegador que utilizas

• si has instalado ex­te­n­sio­nes para el navegador

• si utilizas un co­r­ta­fue­gos o te conectas a Internet mediante un proxy

Toda esta in­fo­r­ma­ción ayuda tanto al equipo de asi­s­te­n­cia técnica como al webmaster a solventar el problema para que puedas volver a navegar por Internet sin co­m­pli­ca­cio­nes con la mayor celeridad posible sin que se aparezca el error HTTP 400.