Codici di stato HTTP: significato e diagnosi : robots

I codici di stato HTTP indicano il risultato di una richiesta tra client e server. Le classi 2xx segnalano successo, 3xx reindirizzamento, 4xx problemi lato richiesta o accesso e 5xx errori del server. La diagnosi deve considerare URL, header, log e comportamento dell’applicazione.

Nota di aggiornamento: Lo stesso codice può avere cause diverse. Prima di correggere controlla risposta completa, redirect, cache, proxy e log del server.

Informazioni aggiornate e controlli essenziali

Questa che segue è la lista completa dei codici di stato e dei relativi messaggi definiti per HTTP.

 

1xx Informational : Richiesta ricevuta, continua l’elaborazione.

100 Continue : Il server ha ricevuto l’header della richiesta e il client deve procedere ad inviare il corpo della richiesta (solitamente nelle richieste di tipo POST).

101 Switching Protocols : Il richiedente ha richiesto di cambiare il protocollo in uso e il server è a conoscenza di ciò che dovrà fare.

 

2xx Success : L’azione è stata ricevuta con successo, compresa ed accettata.

200 OK : Risposta standard per le richieste HTTP andate a buon fine.

201 Created

202 Accepted : La richiesta di elaborazione è stata accettata ma non è ancora terminata.

203 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi-Status : In caso di risposte XML, quando più azioni possono essere richieste, i dettagli dei singoli stati sono dati nel corpo della risposta. Vedi WebDAV (RFC 4918) per le specifiche associate.

 

3xx Redirezione : Il client deve eseguire ulteriori azioni per soddisfare la richiesta.

300 Multiple Choices

301 Moved Permanently : Questa è tutte le future richieste andranno dirette ad un altro URI (specificato nell’header Location).

302 Found : Questo è il codice più usato ma anche un classico esempio di non aderenza agli standard nella pratica quotidiana. Infatti, le specifiche di HTTP/1.0 (RFC 1945) richiederebbero che il client esegua redirezioni temporanee (la descrizione originale era “Moved Temporarily”), ma i più diffusi browser l’hanno implementata come 303 descritta di seguito. Perciò, HTTP/1.1 ha aggiunto i codici di stato 303 e 307 per distinguere tra i due comportamenti. Comunque, la maggior parte delle applicazioni e dei framework web ancora usano il codice di stato 302 come se fosse il 303.

303 See Other (da HTTP/1.1) : La risposta alla richiesta può essere trovata sotto un’altra URI usando il metodo GET.

304 Not Modified

305 Use Proxy (da HTTP/1.1) : Molti client HTTP (come Mozilla ed Internet Explorer) non gestiscono correttamente le risposte con questo codice di stato.

306 Switch Proxy : Non più usato.

307 Temporary Redirect (da HTTP/1.1) : In quest’occasione, la richiesta dovrebbe essere ripetuta con un’altra URI, ma successive richieste possono essere ancora dirette a quella originale. In contrasto con 303, la richiesta di POST originale deve essere reiterata con un’altra richiesta di tipo POST.

 

4xx Client Error : La richiesta è sintatticamente scorretta o non può essere soddisfatta.

400 Bad Request : La richiesta non può essere soddisfatta a causa di errori di sintassi.

401 Unauthorized : Simile a 403/Forbidden, ma pensato per essere usato quando l’autenticazione è possibile ma è fallita o non può essere fornita.

402 Payment Required : L’intendimento originale prevedeva un suo utilizzo per realizzare meccanismi di digital cash/micropagamento, ma questo non si è mai verificato ed il codice non è mai stato utilizzato.

403 Forbidden : La richiesta è legittima ma il server si rifiuta di soddisfarla. Contrariamente al codice 401 Unauthorized, l’autenticazione non ha effetto.

404 Not Found : La risorsa richiesta non è stata trovata ma in futuro potrebbe essere disponibile.

405 Method Not Allowed : La richiesta è stata eseguita usando un metodo non permesso. Ad esempio questo accade quando di usa il metodo GET per inviare dati da presentare con un metodo POST.

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout : Il tempo per inviare la richiesta è scaduto e il server ha terminato la connessione.

409 Conflict

410 Gone : Indica che la risorsa richiesta non è più disponibile e non lo sarà più in futuro.

411 Length Required : La richiesta non specifica la propria dimensione come richiesto dalla risorsa richiesta.

412 Precondition Failed 413 Request Entity Too Large : La richiesta è più grande di quanto il server possa gestire.

414 Request-URI Too Long : L’URI richiesto è troppo grande per essere processato dal server.

415 Unsupported Media Type : L’entità della richiesta è di un tipo non accettato dal server o dalla risorsa richiesta.

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot : Questo è un tipico pesce d’aprile dell’ITEF (RFC 2324). Non si aspettano implementazioni in alcun server HTTP.

426 Upgrade Required (RFC 2817) : Il client dovrebbe cambiare il protocollo ed usare ad esempio il TLS/1.0. 449 Retry With Estensione di Microsoft: The request should be retried after doing the appropriate action.

 

5xx Server Error : Il server ha fallito nel soddisfare una richiesta apparentemente valida.

500 Internal Server Error : Messaggio di errore generico senza alcun dettaglio.

501 Not Implemented : Il server non è in grado di soddisfare il metodo della richiesta.

502 Bad Gateway

503 Service Unavailable : Il server non è al momento disponibile. Generalmente è una condizione temporanea.

504 Gateway Timeout

505 HTTP Version Not Supported : Il server non supporta la versione HTTP della richiesta.

509 Bandwidth Limit Exceeded : Questo codice di stato, benché usato da molti server, non è un codice di stato ufficiale in quanto non è specificato in alcuna RFC.

 

 

Approfondimenti correlati

Fonte ufficiale: MDN: codici di stato HTTP.

Domande frequenti

Qual è la differenza tra 404 e 410?

404 indica risorsa non trovata o non disponibile; 410 comunica che la risorsa è stata rimossa intenzionalmente e in modo presumibilmente definitivo.

Cosa significa errore 500?

È una risposta generica del server. Per individuarne la causa servono log applicativi e web server, modalità debug controllata e verifica delle modifiche recenti.

Un redirect 301 è sempre corretto?

Solo quando lo spostamento è permanente e la destinazione è realmente equivalente. Catene e redirect inutili possono creare problemi.

Il file robots.txt comunica ai crawler quali percorsi possono o non possono visitare. Non protegge contenuti riservati e non garantisce la rimozione dall’indice: per questo servono autenticazione, noindex o gestione degli URL secondo il caso.

Nota di aggiornamento: Una regola errata può bloccare risorse o sezioni importanti. Prima della pubblicazione verifica sintassi, maiuscole, percorsi e comportamento con gli strumenti del motore di ricerca.

Informazioni aggiornate e controlli essenziali

Il file robots.txt è un semplice file di testo che contiene delle regole usate dagli Spider (Crawler) per applicare restrizioni sulle pagine di un sito web. I Web Crawler sono dei software programmati che effettuano ricerche sul Web e indicizzazioni per i motori di ricerca, quando analizzano un sito web controllano l’esistenza del file Robots.txt e se vi trovano delle regole o restrizioni le applicano.

Il file robots.txt viene inserito nella directory principale di un sito web ed è puramente consultivo, non tutti gli Spider applicano le regole inserite in esso.

 

Perché è un file robots.txt è importante?

Per evitare lo spreco di risorse del server, molti, se non la maggior parte dei siti web, hanno degli script che girano sul loro sito web che non hanno nessuna utilità pratica per un motore di ricerca, quando i robot dei motori  indicizzano il sito è possibile tramite il file robots.txt impedire agli spider l’indicizzazione di tali script, riducendo il carico sul server e eliminando le esecuzioni non necessarie.

 

Ridurre la larghezza di banda

Se guardate le statistiche del vostro sito web, troverete molte richieste per il Robots.txt da parte degli spider dei motori di ricerca. I motori di ricerca tentano di recuperare il robots.txt prima di indicizzare il sito web, per vedere se ha istruzioni per loro.

Se non si dispone di un file robots.txt, il server restituisce una pagina di errore 404 per il motore, questo causa l’utilizzo di molta banda a causa delle sue ripetute richieste per recuperare il file 404.

Qualche motore di ricerca indicizza anche i file grafici tipo .Gif, .Jpg e .Png, se si desidera bloccarli per risparmiare banda, lo si può fare usando il file robots.txt.

 

Come impostare un file robots.txt

Scrivere un file robots.txt è estremamente semplice. E’ solo un file di testo ASCII che si colloca alla radice del vostro dominio. Ad esempio, se il dominio è www.esempio.com, bisognerà inserire il file in www.esempio.com/robots.txt.

Per coloro che non sanno cosa sia un file di testo ASCII, è solo un file di testo che si crea con un editor di testo. Se utilizzate Windows, è già presente un editor di testo sul vostro sistema, chiamato Blocco note.

Il file Robots.txt elenca fondamentalmente i nomi degli Spider su una linea, seguito da un elenco di directory o file da non indicizzare.

Ogni riga del file contiene un record. Ogni record ha la seguente sintassi :

<campo> : <valore>

I campi disponibili sono :

User-Agent il valore di questo campo contiene il nome del robot che si deve attenere alle restrizioni. Con il carattere * la regola viene applicata a qualsiasi robot.

Disallow il valore di questo campo contiene le pagine del sito che devono essere escluse dai robot durante l’indicizzazione. Si può indicare un URL specifico o una serie di URL appartenenti ad un pattern. Per ogni User-Agent è possibile specificare una o più restrizioni tramite Disallow.

Il file robots.txt è case sensitive quindi se blocchiamo la pagina /PAGINA_DA_BLOCCARE sarà differente da bloccare la pagina /pagina_da_bloccare.

 

Esempio (1) file robots.txt

Per permettere l’accesso a tutto il sito web, non indicare nulla nella direttiva Disallow. Alcuni crawler supportano anche la direttiva Allow

User-agent: *
Disallow:

Per bloccare un intero sito, utilizza una barra.

User-agent: *
Disallow: /

Per bloccare una directory e il relativo contenuto, fai seguire il nome della directory da una barra.

User-agent: *
Disallow: /private_directory/

Per bloccare una pagina, indica tale pagina.

User-agent: *
Disallow: /private_file.html

Per segnalare il file Sitemap del sito.

Sitemap: http://www.esempio.com/sitemap.xml

 

Esempio (2) file robots.txt

User-agent: *
Disallow: /cgi-bin/

Le due righe sopra, inserite in un file robots.txt, informano tutti i robot che non sono autorizzati ad accedere nella directory e nelle sottodirectory di cgi-bin.

 

E’ possibile, bloccare i robot che indicizzano le immagini, tipo Google Image Search, inserendo le righe seguenti:

User-agent: Googlebot-Image
Disallow: /

Ciò significa che il robot di Google Image Search, non dovrebbe tentare di accedere a qualsiasi file nella directory radice / e in tutte le sue sottodirectory.

 

È possibile avere più linee Disallow per ogni user agent (cioè, per ogni spider). Ecco un esempio di file robots.txt più lungo:

User-agent: *
Disallow: /images/
Disallow: /cgi-bin/
User-agent: Googlebot-Image
Disallow: /

 

E’ possibile escludere l’indicizzazione di un determinato file. Per esempio, se non volete fare indicizzare l’immagine test.jpg, dovrete aggiungere le seguenti righe:

User-agent: Googlebot-Image
Disallow: /images/test.jpg

 

Senza restrizioni

Se si desidera che tutte le directory vengano indicizzate da tutti i motori di ricerca, basta un semplice file robots con le seguenti righe:

User-agent: *
Disallow:

 

Alla prossima.

 

 

Approfondimenti correlati

Fonte ufficiale: Google Search Central: robots.txt.

Domande frequenti

Robots.txt rimuove una pagina da Google?

Non in modo affidabile. Blocca la scansione, ma un URL può essere conosciuto tramite collegamenti. Per la deindicizzazione occorrono strumenti appropriati.

Si possono inserire dati riservati nel robots.txt?

No. Il file è pubblico e non è un sistema di sicurezza. Le aree private devono essere protette con autenticazione e permessi.

Dove si trova il file?

Normalmente nella radice del protocollo e host, ad esempio https://example.com/robots.txt. Le regole valgono soltanto per quello specifico host.

Il tuo sito è stato segnalato come sito infetto da malware dai motore di ricerca? E ‘un incubo per un webmaster sapere che il proprio sito è stato segnalato come pericoloso da un motore di ricerca, il traffico può calare vertiginosamente e sarete costretti a correggere il tutto per evitare gravi danni di credibilità del vostro sito.

E’ molto difficile per un webmaster medio controllare il codice sorgente di ogni pagina web e scoprire che cosa sta causando il danno. Inoltre è difficile trovare i codici nascosti che sono il reindirizzamento ad alcuni altri codici maligni, ci possono essere molti link nascosti spam difficili da trovare.

Un ottimo strumento, praticissimo e certamente autorevole è Google. Digitando nella barra google.it/safebrowsing/diagnostic?site= seguito dal sito da verificare. Google ci fornirà immediatamente tutti i dati in suo possesso riguardanti il sito, se il risultato restituito è Questo sito non è contrassegnato attualmente come sospetto, il sito è pulito.

Tuttavia, ci sono degli strumenti online che possono aiutarvi a controllare se il vostro sito è infetto da malware.

 

5 Tools contro il Malware

 

Questo servizio esegue la scansione di un URL o di un dominio. Cliccando su Scan Now verrà scansionato il sito e se il sito è pulito, otterrete la voce Status: CLEAN, mentre in caso di infezione, i risultati della scansione potranno essere molto utili per identificare il problema legato alla sicurezza.

Visita URLVoid

 

 

Il Tools della Sucuri è molto interessante, analizza se il sito è in una BlackList, effettua una scansiona Malware ed individua l’infezione presente in un sito internet. Cliccando su Verify sarà eseguita la verifica del Sito Web gratuitamente, mentre la versione a pagamento di Sucuri, offre un monitoraggio costante con alert e  mette a disposizione un team di esperti che vi risolveranno il problema.

Visita Sucuri.net

 

 

PhishTank è una comunità libera dove chiunque può presentare, verificare, monitorare e condividere i dati di phishing. PhishTank è gestita da OpenDNS , una società fondata nel 2005 per migliorare la connessione a Internet attraverso i suoi DNS. Cliccando su Is It a Phish? verrà controllato se il sito web è inserito nella lista dei siti web considerati pericolosi, se il risultato è Nothing known about il sito è pulito.

Visita PhishTank

 

 

 

AVG LinkScanner consente di verificare la sicurezza delle singole pagine web del vostro sito o del sito che state per visitare. LinkScanner esaminerà la pagina web in tempo reale, per vedere se sta nascondendo dei link sospetti.

Visita AVG LinkScanner

 

 

 

Questo tool online consente di eseguire la scansione di link sospetti che potrebbero portare a pericolose minacce che possono attaccare un computer, di conseguenza è possibile verificare se un indirizzo web è ritenuto affidabile.

Visita OnlineLinkScan

 

Alla Prossima.