Controllo header HTTP

Uno strumento di controllo degli header HTTP mostra i metadati restituiti da un server per un URL. Screpy esegue una richiesta GET pubblica, segue i reindirizzamenti supportati ed elenca nomi e valori degli header della risposta finale senza scaricare il corpo della pagina. Usa il rapporto per indagare su un reindirizzamento, controllare una modifica dopo la pubblicazione o trovare un'istruzione di indicizzazione inattesa.

Parti dalla risposta ricevuta e confrontala con il comportamento previsto per quella risorsa. Un controllo completato può mostrare un errore del server o una politica inadeguata. Un risultato verde non certifica sicurezza, prestazioni della cache o indicizzazione nei motori di ricerca.

Controlla l'URL esatto e la catena delle risposte

Inserisci un indirizzo HTTP o HTTPS pubblico completo, con percorso e parametri pertinenti. Homepage, PDF e pagina prodotto possono restituire header diversi sullo stesso dominio. Per una pagina prodotto fittizia, https://example.com/products/blue-mug/ è più utile della radice se vuoi esaminare proprio quella risposta.

Leggi la catena prima della tabella. Un reindirizzamento può cambiare protocollo, host o percorso. La tabella contiene gli header della risposta finale, non tutti gli header di ogni passaggio. La catena comprende anche la risposta finale, quindi il numero di passaggi non coincide necessariamente con quello dei reindirizzamenti.

Verifica che l'URL finale sia la risorsa desiderata. Una pagina di accesso, di errore o un host diverso possono spiegare valori inattesi. Usa Redirect Checker quando ti interessa soprattutto il percorso dei reindirizzamenti anziché l'elenco finale degli header.

Leggi un esempio di risposta HTTP

Questa risposta fittizia mostra come campi diversi rispondano a domande diverse. Non è una scansione acquisita né una configurazione da copiare su ogni pagina.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex

Lo stato 200 indica una risposta riuscita. Content-Type dichiara HTML con codifica UTF-8. Cache-Control descrive le istruzioni di cache, mentre X-Robots-Tag contiene un'istruzione di indicizzazione. Una risposta funzionante può quindi includere noindex: il successo HTTP non significa che la pagina sia destinata ai risultati di ricerca.

La tabella normalizza i nomi in minuscolo; le maiuscole non creano campi diversi. Il riferimento MDN sugli header distingue campi di richiesta e risposta. Lo strumento mostra la risposta, non i cookie, le preferenze o i dati di autenticazione della tua sessione nel browser.

Valuta cache e indicizzazione come decisioni distinte

Filtra per nome dell'header quando indaghi su un problema specifico. Prima chiarisci le esigenze della risorsa: HTML aggiornato spesso, un file con versione e un documento volutamente escluso dalla ricerca non richiedono necessariamente la stessa politica.

no-cache non significa «non memorizzare mai». Consente la memorizzazione, ma richiede una validazione prima del riutilizzo. no-store indica alle cache di non conservare la risposta. Il riferimento MDN su Cache-Control spiega la differenza. Questo controllo non misura gli accessi serviti dalla cache e non elimina copie già memorizzate.

Un'istruzione di indicizzazione è separata dalla freschezza del contenuto. Se una pagina destinata all'indice restituisce noindex inaspettatamente, individua l'applicazione, l'impostazione del server o la regola responsabile prima di modificarla. Usa Noindex Checker per esaminare anche le direttive HTML. La documentazione noindex di Google spiega l'istruzione; osservarla non dimostra lo stato attuale nell'indice Google.

Comprendi le osservazioni sugli header di sicurezza

Screpy evidenzia alcune dichiarazioni da esaminare. Tratta il risultato come una domanda di configurazione, non come un rapporto di vulnerabilità o un invito a copiare una politica sconosciuta in produzione.

Un'indicazione informativa o una politica assente non provano una vulnerabilità. Allo stesso modo, un header presente non rende efficace una politica. La documentazione CSP di MDN distingue le politiche applicate da Content-Security-Policy-Report-Only, che segnala violazioni senza imporre quelle restrizioni. Vedere quest'ultimo non dimostra la presenza di una politica vincolante.

Valuta i cambiamenti in base alle reali risorse ed esigenze di incorporamento dell'applicazione. Lo strumento non assegna voti di sicurezza, ispeziona certificati o convalida ogni direttiva. Per riferimenti a risorse non sicure nell'HTML, usa separatamente Mixed Content Checker.

Interpreta i valori ripetuti e nascosti

Il numero di header indica nomi normalizzati distinti. La colonna delle occorrenze mostra quante volte un nome è apparso, mentre i normali valori ripetuti restano visibili. Più occorrenze non sono automaticamente un errore: verifica se il campo permette quella struttura e se la politica combinata è voluta.

I valori sensibili di cookie, autenticazione e segreti riconosciuti vengono nascosti o ripuliti. Un valore nascosto non equivale a un header assente, e la sua presenza non è una valutazione della sicurezza dei cookie. Non reinserire valori oscurati in un rapporto condiviso. Esamina i dettagli riservati solo in un ambiente privato di debug adeguato.

Filtra per nome, come cache-control, senza aspettarti una ricerca in tutti i valori. Conserva il rapporto con URL e orario della verifica per confrontare le risposte. Interpreta la presenza o assenza di un campo insieme a stato finale, tipo di risorsa e avviso di copertura.

Distingui controlli parziali ed errori HTTP

Un errore restituito dal server è diverso dall'impossibilità di raggiungerlo. Leggi il messaggio di copertura prima di interpretare righe assenti.

Lo strumento segue un numero limitato di reindirizzamenti e attende per un tempo limitato. Cicli, destinazioni irraggiungibili o risposte oltre i limiti supportati possono lasciare il controllo incompleto. In quel caso, un elenco finale vuoto non è una lista di header di sicurezza mancanti.

Indirizzi di rete privata, pagine autenticate e richieste che necessitano dei cookie del tuo browser sono fuori dall'ambito del modulo. Una restrizione di accesso non dimostra nemmeno cosa ricevano Googlebot o altri visitatori reali.

Confronta gli header dopo la pubblicazione

Prima di una modifica, annota URL esatto, risposta finale, orario e campo che dovrebbe cambiare. Esporta il rapporto come riferimento. Dopo aver pubblicato la configurazione prevista, controlla lo stesso URL e confronta i valori pertinenti, non solo il numero di header o avvisi. Ripeti con un altro tipo di risorsa se la regola dovrebbe valere anche lì.

Se il browser mostra altro, apri il pannello Rete, ricarica la pagina ed esamina la richiesta pertinente. Confronta URL dopo i reindirizzamenti, metodo e stato di accesso. Una risposta personalizzata o memorizzata nella cache può differire da una richiesta pubblica da un'altra posizione. Il modulo non invia i tuoi cookie e non permette di aggiungere header di autenticazione personali.

Controlla anche se un altro strumento usa HEAD invece di GET. RFC 9110 spiega che HEAD non contiene un corpo e può omettere campi determinati durante la generazione del contenuto. Screpy usa GET, ma si ferma prima di scaricare il corpo. Allineare metodo e condizioni aiuta a indagare una differenza; non rende identiche tutte le risposte del server.