Ti è piaciuto l’articolo?
0
Ti è piaciuto l’articolo?
0

HTTP 400 Bad Request: spiegazione

Navigando quotidianamente 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 desiderato. Durante la comunicazione tra il server web e il client, che corrisponde 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 comunicazione 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 spieghiamo che cosa si nasconda esattamente dietro questo messaggio di errore e vi forniamo i consigli necessari per riuscire a risolvere questo problema.

A che cosa corrisponde l’errore Bad Request 400?

Con i codici di stato il web server comunica al client lo stato delle sue richieste. Se il server risponde con la comunicazione 200, la quale solitamente non viene neanche visualizzata durante la navigazione, allora significa che sta funzionando tutto come dovrebbe: la richiesta è andata a buon fine e i contenuti desiderati 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 comunicazioni di questo tipo non vengono visualizzate quasi mai dagli utenti, come anche quelle relative ai 300: qui la comunicazione tra server e client ha funzionato, ma il client deve ancora effettuare un ultimo passaggio. In questo caso si tratta soprattutto di reindirizzamenti, che il browser effettua in maniera quasi del tutto automatica facendo sì che i messaggi relativi passino praticamente inosservati agli occhi degli utenti.

Il discorso cambia con i messaggi di errore: mentre il gruppo degli errori 500 fa riferimento ad errori appunto, ma dal lato del server, tutto ciò che ricade nei 400 corrisponde ad una richiesta errata o incompleta da parte del client. Il messaggio di errore più celebre è probabilmente l’errore 404 Not Found (404 pagina non trovata). La causa all’origine della comunicazione è 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 protocollo Internet HTTP non è stato rispettato, almeno questo è quello che ha riscontrato il server web; e per questo motivo la richiesta non può essere elaborata. Il server avrà infatti interpretato la richiesta come incorretta o dannosa, bloccando perciò conseguentemente la visulizzazione delle pagine del sito web. I motivi per tale comunicazione nella maggior parte dei casi ha a che fare con il browser utilizzato o vanno ricondotte ad un errore commesso dall’utente:

  • URL sbagliato: sussiste una Bad Request, esattamente come per l’errore 404, se l’utente indica un indirizzo Internet errato, ad esempio includendo nell’URL dei caratteri speciali non consentiti;
  • Cookies difettosi: se i cookies all’interno del vostro browser sono scaduti o errati, si può incappare in un errore 400;
  • Dati DNS non aggiornati: nella cartella cache del DNS nel vostro browser potrebbero essere presenti dei dati che rimandano a indirizzi IP non corretti;
  • File troppo pesanti: se tentate di caricare dei file di dimensioni particolarmente grandi, il server potrebbe rifiutarli. Anche questo verrebbe contrassegnato come Bad Request da parte del server;
  • Header troppo lunghi: nelle loro comunicazioni il client e il server utilizzano gli header (intestazione), all’interno dei quali è definita la richiesta. Alcuni server web stabiliscono una lunghezza massima che gli header non devono superare.

Quindi quando ci si imbatte in una “HTTP 400 Bad Request” non è immediatamente chiaro da che cosa derivi il problema. Nel caso in cui il server di riferimento utilizzi il web server IIS 7.0, IIS 7.5 o IIS 8.0, allora sarà possibile leggere delle informazioni più dettagliate dal codice di stato:

  • 400.1: Destination 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 solitamente solo durante la navigazione all’interno di un browser, anche altri programmi come ad esempio i client di posta possono ricevere il codice di stato durante la comunicazione con un server.

HTTP 400 Bad Request: risoluzione

Come nel caso della maggior parte dei codici di stato che mostrano un messaggio di errore, il più delle volte basterà semplicemente ricaricare la pagina. Soprattutto se è la prima volta che compare l’errore durante la visita ad un sito web, che altrimenti riuscite a richiamare senza problemi, allora potrebbe darsi che si tratti di un problema temporaneo. Se ricaricare la pagina non dovesse risolvere il problema, a volte allora è sufficiente 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 manualmente l’indirizzo all’interno dell’apposita riga nel browser, controllate che non abbiate digitato in maniera errata. Se avete invece cliccato su di un link, anche lì potete controllare la correttezza dell’URL o eventualmente decidere di visitare prima la homepage per poi riuscire a raggiungere la sottopagina desiderata muovendovi direttamente 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 semplicemente i dati corrispettivi nel vostro browser. Una volta fatto vi basterà richiamare di nuovo il sito, così che il software crei un nuovo cookie.

Fatto

Nei cookies vengono salvate informazioni relative alla vostra visita ad un sito web. In questo modo il server web sa se avete visitato il sito web in passato e come vi siete comportati durante la vostra permanenza. A protezione della sfera privata degli utenti è entrata in vigore la normativa dell’Unione Europea atta a mantenere la riservatezza dei dati raccolti tramite 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 connessione nel World Wide Web. Per prima cosa è necessario effettuare una risoluzione dei nomi presso un DNS o name server. Per velocizzare questo processo, il vostro PC salva temporaneamente i dati raccolti nella cache DNS. In questo modo la prossima volta che inserirete il dominio nel browser, a patto che nel frattempo i dati ad esso relativi non siano stati cancellati automaticamente dalla cache, la risoluzione dei nomi avverrà direttamente nella cache. Se però tali dati sono invece corrotti o non più attuali, allora riceverete il messaggio di errore “HTTP Bad Request”.

Per rimuovere i dati errati è necessario 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 -flushcache
  • OS X 10.5 (Leopard): dscacheutil -flushcache
  • OS X 10.6 (Snow Leopard): dscacheutil - flushcache
  • OS X 10.7 (Lion): sudo killall -HUP mDNSResponder
  • OS X 10.8 (Mountain Lion): sudo killall -HUP mDNSResponder
  • OS X 10.9 (Mavericks): dscacheutil -flushcashe; sudo killall -HUP mDNSResponder
  • OS X 10.10 (Yosemite) (10.10.1 – 10.10.3): sudo discoverutil udnsflashcaches
  • OS X 10.10 (Yosemite) (10.10.4+): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • OS X 10.11 (El Capitan): sudo killall -HUP mDNSResponder
  • macOS 10.12 (Sierra): sudo killall -HUP mDNSResponder

Problemi con i campi di header HTTP

In quanto utenti: eliminare i cookies e reimpostare il browser

Come già anticipato, un altro motivo per cui si ottiene l’errore HTTP 400 è quando l’header HTTP è troppo lungo. In teoria gli header non hanno alcun limite massimo di lunghezza, ma potrebbe essere che il server di destinazione ne abbia impostato uno. L’header consiste di più campi, all’interno dei quali vengono definite le richieste e le risposte. Quando i parametri di entrambe le parti corrispondono, verranno scambiati i dati richiesti. Se ciò non dovesse funzionare, si riceverà un messaggio di errore. Trattandosi di una comunicazione tra browser e server web e derivando solitamente gli errori 400 da problemi con il client, è probabile che il browser sia responsabile per l’errore. Il modo migliore per testare se il browser che siamo soliti utilizzare abbia causato il problema è quello di fare una prova con un altro browser.

Dovesse filare tutto liscio con l’utilizzo di un altro browser, allora tornate al vostro browser prediletto, quindi cancellate come prima cosa i vostri cookie (sempre che non lo abbiate già fatto durante un altro tentativo di risoluzione del problema). Questa volta però non cancellate solamente un cookie mirato, ma tutti, in modo da andare sul sicuro. Il motivo sta nel fatto che assieme all’intestazione vengono trasmessi anche dei cookie, contenuti al suo interno, facendo sì che il server web sia già a conoscenza della vostra visita precedente. Se il browser dovesse raccogliere troppi dati all’interno di una richiesta, allora l’header potrebbe superare il limite di lunghezza.

Se anche questo tentativo non va a buon fine, allora può valere la pena di provare a reimpostare le impostazioni standard del browser, se non addirittura di reinstallarlo completamente. In base al browser da voi utilizzato, ci sono diversi modi per ritornare alle impostazioni di partenza.

Su Firefox si utilizza il comando about:support nella sezione di supporto per la risoluzione dei problemi. Qui troverete tra l’altro una serie di informazioni che vi possono essere di grande aiuto nell’individuazione di errori all’interno del software. Sulla stessa pagina troverete inoltre il pulsante “Ripristina Firefox”, la cui funzione è spiegata in maniera univoca dal nome. Cliccandoci sopra il software memorizzerà per prima cosa le impostazioni attuali da voi preferite per poi cancellare le estensioni e molte altre impostazioni.

Con Internet Explorer tra le “Opzioni Internet” trovate sotto la tab “Avanzate” il pulsante “Reimposta”. Il browser di Microsoft vi lascia la scelta se volete mantenere o cancellare le vostre impostazioni personali durante il ripristino. Essendo che Internet Explorer considera tra queste anche la cache e i cookie, è consigliabile sbarazzarsi di tutto.

Con Chrome trovate la funzione per il ripristino tra le impostazioni di sistema. Il browser conserverà i vostri dati personali come le password salvate e la cronologia, ma per il resto reimposterà completamente le opzioni standard. Chiudete il browser e riavviatelo, per rendere effettive le modifiche apportate.

In quanto webmaster: aumentare i limiti

Se siete dei webmaster e i vostri visitatori si sono lamentati per via della ricorrenza del codice di errore 400, allora potrebbe essere il caso di apportare delle modifiche alle impostazioni del server. Per fare in modo che gli utenti del vostro sito web non ricevano più la comunicazione per via di un HTTP header oltre i limiti, quello che potete fare è proprio stabilire dei limiti maggiori. Dovreste però essere anche consapevoli del fatto che con dei limiti più alti aumenta anche il rischio di richieste dannose. La Internet Engineering Task Force (IETF), nella propria documentazione relativa all’HTTP 1.1, ha affrontato anche la questione del codice di errore 400 Bad Request, avvisando del rischio che si corre con dei limiti troppo alti (Smuggling Attacks):

Citazione

“A server that receives a request header field, or set of fields, larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 9.5).”

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

Desiderate comunque aumentare i limiti? Ogni server web ha il proprio metodo. Con IIS (ASP.NET) dovete cambiare “maxRequestLength” e “maxAllowedContentLength”. Con Apache al contrario stabilite il limite con il comando “LimitRequestFieldSize”.

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 teoricamente due persone che potete contattare. Se si tratta del primo caso, e le soluzioni tentate non hanno portato i frutti desiderati, allora non vi rimane che contattare il webmaster della pagina, o quantomeno tentare. Nel caso contrario, ovvero se non riuscite praticamente 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 effettivamente dal provider stesso, l’assistenza cliente potrebbe essere in grado di aiutarvi.

In entrambi i casi fornite ai vostri referenti tutte le informazioni di cui disponete. Questo comprende anche tutti i tentativi di risoluzione che avete messo in opera. Utili risultano anche i dati relativi al vostro sistema operativo, come ad esempio: quale sistema operativo utilizzate? Con quale browser navigate sul web? Avete installato delle estensioni del browser? Utilizzate un firewall o un proxy? Tutte queste informazioni non servono solamente ad aiutare il team di supporto del provider, ma anche il webmaster. A questo punto dovreste essere in grado di navigare indisturbati in Internet, senza che vi continui a comparire l’errore “400”.

Protocollo HTTP