HTTP 400 Bad Request: spie­ga­zio­ne

Navigando quo­ti­dia­na­men­te in Internet non sempre va tutto sempre solo per il verso giusto. A volte il browser vi mostra un codice di stato al posto del contenuto de­si­de­ra­to. Durante la co­mu­ni­ca­zio­ne tra il server web e il client, che cor­ri­spon­de poi al vostro browser, vi vengono mostrati dei messaggi di stato basilari, ma non appena invece si presenta un problema, allora la finestra del vostro browser vi mostrerà una co­mu­ni­ca­zio­ne d’errore più o meno criptica. L’avviso del codice HTTP 400 vi segnala che qualcosa è andato storto durante la richiesta del vostro client. Perciò in questo articolo vi spie­ghia­mo che cosa si nasconda esat­ta­men­te dietro questo messaggio di errore e vi forniamo i consigli necessari per riuscire a risolvere questo problema.

Con i codici di stato il web server comunica al client lo stato delle sue richieste. Se il server risponde con la co­mu­ni­ca­zio­ne 200, la quale so­li­ta­men­te non viene neanche vi­sua­liz­za­ta durante la na­vi­ga­zio­ne, allora significa che sta fun­zio­nan­do tutto come dovrebbe: la richiesta è andata a buon fine e i contenuti de­si­de­ra­ti sono stati trasmessi. Diversa è la storia con i codici 400 e 500: questi segnalano errori di diverso tipo. Tutto ciò che si trova tra i codici di stato nella serie dei 100 indica che il processo è ancora in atto e quello presente nei 200 segnala che i processi sono andati a buon fine. Le co­mu­ni­ca­zio­ni di questo tipo non vengono vi­sua­liz­za­te quasi mai dagli utenti, come anche quelle relative ai 300: qui la co­mu­ni­ca­zio­ne tra server e client ha fun­zio­na­to, ma il client deve ancora ef­fet­tua­re un ultimo passaggio. In questo caso si tratta so­prat­tut­to di rein­di­riz­za­men­ti, che il browser effettua in maniera quasi del tutto au­to­ma­ti­ca facendo sì che i messaggi relativi passino pra­ti­ca­men­te inos­ser­va­ti agli occhi degli utenti. Il discorso cambia con i messaggi di errore: mentre il gruppo degli errori 500 fa ri­fe­ri­men­to ad errori appunto, ma dal lato del server, tutto ciò che ricade nei 400 cor­ri­spon­de ad una richiesta errata o in­com­ple­ta da parte del client. Il messaggio di errore più celebre è pro­ba­bil­men­te l’errore 404 Not Found (404 pagina non trovata). La causa all’origine della co­mu­ni­ca­zio­ne è di norma un URL sbagliato o un contenuto rimosso. Nel caso dell’errore 400 è difficile trovare una risposta alla domanda “che cosa è andato storto?”. Per un motivo o per un altro la richiesta è stata posta in maniera errata. Il pro­to­col­lo Internet HTTP non è stato ri­spet­ta­to, almeno questo è quello che ha ri­scon­tra­to il server web; e per questo motivo la richiesta non può essere elaborata. Il server avrà infatti in­ter­pre­ta­to la richiesta come in­cor­ret­ta o dannosa, bloccando perciò con­se­guen­te­men­te la vi­su­liz­za­zio­ne delle pagine del sito web. I motivi per tale co­mu­ni­ca­zio­ne nella maggior parte dei casi ha a che fare con il browser uti­liz­za­to o vanno ri­con­dot­te ad un errore commesso dall’utente:

• URL sbagliato: sussiste una Bad Request, esat­ta­men­te come per l’errore 404, se l’utente indica un indirizzo Internet errato, ad esempio in­clu­den­do nell’URL dei caratteri speciali non con­sen­ti­ti;

• Cookies difettosi: se i cookies all’interno del vostro browser sono scaduti o errati, si può incappare in un errore 400;

• Dati DNS non ag­gior­na­ti: nella cartella cache del DNS nel vostro browser po­treb­be­ro essere presenti dei dati che rimandano a indirizzi IP non corretti;

• File troppo pesanti: se tentate di caricare dei file di di­men­sio­ni par­ti­co­lar­men­te grandi, il server potrebbe ri­fiu­tar­li. Anche questo verrebbe con­tras­se­gna­to come Bad Request da parte del server;

• Header troppo lunghi: nelle loro co­mu­ni­ca­zio­ni il client e il server uti­liz­za­no gli header (in­te­sta­zio­ne), all’interno dei quali è definita la richiesta. Alcuni server web sta­bi­li­sco­no una lunghezza massima che gli header non devono superare.

Quindi quando ci si imbatte in una “HTTP 400 Bad Request” non è im­me­dia­ta­men­te chiaro da che cosa derivi il problema. Nel caso in cui il server di ri­fe­ri­men­to utilizzi il web server IIS 7.0, IIS 7.5 o IIS 8.0, allora sarà possibile leggere delle in­for­ma­zio­ni più det­ta­glia­te dal codice di stato:

• 400.1: De­sti­na­tion Header non valido;
• 400.2: Depth Header non valido;
• 400.3: If Header non valido;
• 400.4: Overwrite Header non valido;
• 400.5: Translate Header non valido;
• 400.6: Request Body non valido;
• 400.7: Content Length non valida;
• 400.8: Timeout non valido;

L’errore 400 non emerge so­li­ta­men­te solo durante la na­vi­ga­zio­ne all’interno di un browser, anche altri programmi come ad esempio i client di posta possono ricevere il codice di stato durante la co­mu­ni­ca­zio­ne con un server.

Come nel caso della maggior parte dei codici di stato che mostrano un messaggio di errore, il più delle volte basterà sem­pli­ce­men­te ri­ca­ri­ca­re la pagina. So­prat­tut­to se è la prima volta che compare l’errore durante la visita ad un sito web, che al­tri­men­ti riuscite a ri­chia­ma­re senza problemi, allora potrebbe darsi che si tratti di un problema tem­po­ra­neo. Se ri­ca­ri­ca­re la pagina non dovesse risolvere il problema, a volte allora è suf­fi­cien­te svuotare la cache del browser. Infatti potrebbe darsi che il vostro browser abbia appena salvato nella cache una copia della pagina all’interno della quale viene mostrato il messaggio errore.

URL errato

Il prossimo passo per l’analisi del problema dovrebbe essere la verifica dell’URL. Nel caso in cui abbiate immesso ma­nual­men­te l’indirizzo all’interno dell’apposita riga nel browser, con­trol­la­te che non abbiate digitato in maniera errata. Se avete invece cliccato su di un link, anche lì potete con­trol­la­re la cor­ret­tez­za dell’URL o even­tual­men­te decidere di visitare prima la homepage per poi riuscire a rag­giun­ge­re la sot­to­pa­gi­na de­si­de­ra­ta muo­ven­do­vi di­ret­ta­men­te all’interno del sito.

Cookies difettosi

Il problema potrebbe derivare anche da cookies non più validi o difettosi. Per risolvere il problema in questo caso, dovete eliminare sem­pli­ce­men­te i dati cor­ri­spet­ti­vi nel vostro browser. Una volta fatto vi basterà ri­chia­ma­re di nuovo il sito, così che il software crei un nuovo cookie.

Dati DNS non corretti

Un’ulteriore possibile soluzione che potete tentare è quella di svuotare la cache del vostro DNS. Se navigate in Internet i nomi di dominio da voi indicati vengono tradotti in indirizzi IP, che sono l’unico modo tramite il quale è possibile stabilire una con­nes­sio­ne nel World Wide Web. Per prima cosa è ne­ces­sa­rio ef­fet­tua­re una ri­so­lu­zio­ne dei nomi presso un DNS o name server. Per ve­lo­ciz­za­re questo processo, il vostro PC salva tem­po­ra­nea­men­te i dati raccolti nella cache DNS. In questo modo la prossima volta che in­se­ri­re­te il dominio nel browser, a patto che nel frattempo i dati ad esso relativi non siano stati can­cel­la­ti au­to­ma­ti­ca­men­te dalla cache, la ri­so­lu­zio­ne dei nomi avverrà di­ret­ta­men­te nella cache. Se però tali dati sono invece corrotti o non più attuali, allora ri­ce­ve­re­te il messaggio di errore “HTTP Bad Request”.

Per rimuovere i dati errati è ne­ces­sa­rio eliminare l’intera cache DNS. Per fare ciò dovete aprire il prompt di Windows e dare il comando di svuotare la cartella cache:

ipconfig /flushdns

Per chi utilizza il sistema operativo del Mac il comando dipende dalla versione OS. Tutti i comandi vanno dati dal terminale:

• OS X 10.4 (Tiger): lookupd -flu­sh­ca­che
• OS X 10.5 (Leopard): dsca­cheu­til -flu­sh­ca­che
• OS X 10.6 (Snow Leopard): dsca­cheu­til - flu­sh­ca­che
• OS X 10.7 (Lion): sudo killall -HUP mDN­SRe­spon­der
• OS X 10.8 (Mountain Lion): sudo killall -HUP mDN­SRe­spon­der
• OS X 10.9 (Mavericks): dsca­cheu­til -flu­sh­ca­she; sudo killall -HUP mDN­SRe­spon­der
• OS X 10.10 (Yosemite) (10.10.1 – 10.10.3): sudo di­sco­ve­ru­til udn­sfla­sh­ca­ches
• OS X 10.10 (Yosemite) (10.10.4+): sudo dsca­cheu­til -flu­sh­ca­che; sudo killall -HUP mDN­SRe­spon­der
• OS X 10.11 (El Capitan): sudo killall -HUP mDN­SRe­spon­der
• macOS 10.12 (Sierra): sudo killall -HUP mDN­SRe­spon­der

In quanto webmaster: aumentare i limiti

Se siete dei webmaster e i vostri vi­si­ta­to­ri si sono lamentati per via della ri­cor­ren­za del codice di errore 400, allora potrebbe essere il caso di apportare delle modifiche alle im­po­sta­zio­ni del server. Per fare in modo che gli utenti del vostro sito web non ricevano più la co­mu­ni­ca­zio­ne per via di un HTTP header oltre i limiti, quello che potete fare è proprio stabilire dei limiti maggiori. Dovreste però essere anche con­sa­pe­vo­li del fatto che con dei limiti più alti aumenta anche il rischio di richieste dannose. La Internet En­gi­nee­ring Task Force (IETF), nella propria do­cu­men­ta­zio­ne relativa all’HTTP 1.1, ha af­fron­ta­to anche la questione del codice di errore 400 Bad Request, avvisando del rischio che si corre con dei limiti troppo alti (Smuggling Attacks):

De­si­de­ra­te comunque aumentare i limiti? Ogni server web ha il proprio metodo. Con IIS (ASP.NET) dovete cambiare “ma­x­Re­que­stLength” e “ma­xAl­lo­we­d­Con­ten­tLength”. Con Apache al contrario stabilite il limite con il comando “Li­mi­tRe­quest­Field­Si­ze”.

Prendere contatto

Purtroppo può anche capitare che nessuna di queste opzioni risolva il vostro problema. Allora la soluzione va ricercata altrove. A seconda che l’errore HTTP 400 vi compaia solo quando cercate di visitare un sito ben preciso o al contrario su molti, se non su tutti i siti web, avete teo­ri­ca­men­te due persone che potete con­tat­ta­re. Se si tratta del primo caso, e le soluzioni tentate non hanno portato i frutti de­si­de­ra­ti, allora non vi rimane che con­tat­ta­re il webmaster della pagina, o quan­to­me­no tentare. Nel caso contrario, ovvero se non riuscite pra­ti­ca­men­te più a navigare poiché qualunque pagina tentate di aprire vi continua a comparire l’errore Bad Request 400, allora ciò che dovreste fare è mettervi in contatto con il vostro Internet provider. Anche nel caso in cui il problema non dipenda ef­fet­ti­va­men­te dal provider stesso, l’as­si­sten­za cliente potrebbe essere in grado di aiutarvi.

In entrambi i casi fornite ai vostri referenti tutte le in­for­ma­zio­ni di cui disponete. Questo comprende anche tutti i tentativi di ri­so­lu­zio­ne che avete messo in opera. Utili risultano anche i dati relativi al vostro sistema operativo, come ad esempio: quale sistema operativo uti­liz­za­te? Con quale browser navigate sul web? Avete in­stal­la­to delle esten­sio­ni del browser? Uti­liz­za­te un firewall o un proxy? Tutte queste in­for­ma­zio­ni non servono solamente ad aiutare il team di supporto del provider, ma anche il webmaster. A questo punto dovreste essere in grado di navigare in­di­stur­ba­ti in Internet, senza che vi continui a comparire l’errore “400”.