Intestazione HTTP: guida tecnica completa agli HTTP header

Cos’è un’intestazione HTTP

Ogni volta che un browser richiede una risorsa a un server web, la comunicazione avviene tramite il protocollo HTTP. Lo scambio si articola in due fasi: una request (dal client al server) e una response (dal server al client). Entrambe le fasi contengono un blocco di metadati testuali chiamato intestazione HTTP (HTTP header).

Le intestazioni HTTP sono coppie chiave: valore separate da un carattere CR-LF (Carriage Return + Line Feed, \r\n), come definito nella RFC 9110. Ogni header fornisce istruzioni precise al client o al server: tipo di contenuto, direttive di cache, politiche di sicurezza, informazioni di autenticazione, encoding supportati.

La prima riga della response non è tecnicamente un header, ma la status line: contiene il protocollo (HTTP/1.1), lo status code numerico e la reason phrase. Le righe successive sono gli header veri e propri.

Ecco un esempio reale degli header di risposta di www.evemilano.com, catturato a febbraio 2026:

HTTP/1.1 200 OK
Date: Thu, 19 Feb 2026 22:50:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Server: cloudflare
vary: Accept-Encoding
link: <https://www.evemilano.com/wp-json/>; rel="https://api.w.org/"
x-fastcgi-cache: HIT
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=15552000; preload
referrer-policy: no-referrer-when-downgrade
permissions-policy: geolocation=(self), camera=(self), midi=(self), sync-xhr=(self), microphone=(self), magnetometer=(self), gyroscope=(self), fullscreen=(self), payment=(self)
cf-cache-status: DYNAMIC
CF-RAY: 9d0953318c9d1f90-MRS
alt-svc: h3=":443"; ma=86400

Dalla response si leggono informazioni operative fondamentali: il server è Cloudflare, la cache FastCGI ha servito la pagina (HIT), HSTS è attivo con preload, la compressione è negoziata tramite Vary: Accept-Encoding. In un singolo blocco di testo, il server comunica al browser tutto ciò che serve per renderizzare, memorizzare e proteggere la risorsa.

---

Tipologie di HTTP header

La RFC 9110 e la precedente RFC 7231 classificano gli HTTP header in quattro categorie in base alla loro funzione e al contesto in cui vengono utilizzati: general header, request header, response header e entity/representation header.

General header

I general header si applicano sia alle request che alle response, senza relazione diretta con il corpo del messaggio. Forniscono informazioni di contesto sulla comunicazione stessa.

Esempi tipici:

• Date — timestamp della generazione del messaggio (es. Date: Thu, 19 Feb 2026 22:50:45 GMT)
• Connection — controlla se la connessione TCP resta aperta dopo la transazione (keep-alive o close)
• Cache-Control — direttive di caching valide per tutti gli intermediari nella catena request-response
• Transfer-Encoding — specifica la codifica di trasferimento applicata al corpo del messaggio (es. chunked)

Request header

I request header vengono inviati dal client al server. Comunicano le preferenze del client (lingue, encoding, tipi MIME accettati), le credenziali di autenticazione e il contesto di navigazione (referer, cookie). Il server utilizza queste informazioni per generare una response adeguata — un meccanismo noto come content negotiation.

Header	Descrizione	Esempio
Host	Dominio richiesto (obbligatorio in HTTP/1.1)	Host: www.evemilano.com
User-Agent	Identificativo del client	User-Agent: Mozilla/5.0...
Accept	Tipi di contenuto accettati	Accept: text/html, application/json
Accept-Language	Lingue preferite dal client	Accept-Language: it-IT, en
Accept-Encoding	Compressioni supportate	Accept-Encoding: gzip, br
Authorization	Credenziali di autenticazione	Authorization: Bearer eyJ...
Cookie	Cookie inviati al server	Cookie: session_id=abc123
Referer	URL di provenienza della richiesta	Referer: https://www.google.com/
Cache-Control	Direttive cache del client	Cache-Control: no-cache
If-Modified-Since	Richiesta condizionale basata sulla data	If-Modified-Since: Thu, 01 Jan 2026
If-None-Match	Validazione tramite ETag	If-None-Match: "33a64df551"

Gli header condizionali If-Modified-Since e If-None-Match sono particolarmente rilevanti per le performance: permettono al browser di validare la cache locale senza scaricare nuovamente la risorsa. Se il server risponde con un 304 Not Modified, il body non viene trasmesso, risparmiando banda e tempo di caricamento.

Response header

I response header vengono inviati dal server al client. Contengono le istruzioni per il browser su come gestire la risorsa ricevuta: caching, sicurezza, redirect, cookie, compressione.

Header	Descrizione	Esempio
Content-Type	Tipo MIME della risorsa	Content-Type: text/html; charset=UTF-8
Content-Length	Dimensione del body in byte	Content-Length: 34820
Content-Encoding	Compressione applicata al body	Content-Encoding: gzip
Cache-Control	Direttive di caching per il client	Cache-Control: max-age=31536000
ETag	Hash univoco della risorsa	ETag: "33a64df551425fcc55e4"
Last-Modified	Data dell’ultima modifica	Last-Modified: Thu, 19 Feb 2026
Set-Cookie	Imposta un cookie nel browser	Set-Cookie: id=abc; HttpOnly; Secure
Location	URL di redirect	Location: https://www.evemilano.com/new/
Server	Software del server	Server: cloudflare
Vary	Header che influenzano la risposta in cache	Vary: Accept-Encoding
X-FastCGI-Cache	Stato della cache FastCGI (Nginx)	X-FastCGI-Cache: HIT

L’header Vary merita attenzione particolare: indica alla cache (browser, CDN, proxy) quali request header rendono la risposta diversa. Un Vary: Accept-Encoding significa che esiste una versione gzip e una non compressa della stessa risorsa, e la cache deve trattarle come entry separate.

Entity/Representation header

Gli entity header (rinominati “representation header” nelle RFC più recenti) descrivono le proprietà del corpo del messaggio. A differenza dei general e request/response header, questi metadati riguardano direttamente la risorsa trasferita.

I principali sono:

• Content-Length — dimensione in byte del body
• Content-Type — tipo MIME e charset (es. text/html; charset=UTF-8)
• Content-Encoding — compressione applicata (gzip, br)
• Content-Language — lingua della risorsa
• Allow — metodi HTTP consentiti per la risorsa (es. GET, POST, HEAD)
• Expires — data di scadenza della risorsa in cache (deprecato a favore di Cache-Control: max-age)

---

HTTP Security Header

Gli HTTP security header sono direttive che il server invia al browser per attivare meccanismi di protezione integrati. Non sostituiscono una corretta implementazione lato codice, ma aggiungono un layer difensivo contro attacchi comuni: clickjacking, MIME sniffing, cross-site scripting, downgrade attacks.

Su questo server, protetto da Cloudflare e Nginx, gli header di sicurezza sono configurati a livello di web server. La tabella seguente elenca i security header più rilevanti con i valori consigliati per un sito in produzione.

Header	Funzione	Valore consigliato
Strict-Transport-Security	Forza HTTPS per tutte le request	max-age=31536000; includeSubDomains; preload
Content-Security-Policy	Limita le sorgenti di risorse caricabili	default-src 'self' https:
X-Content-Type-Options	Previene il MIME sniffing	nosniff
X-Frame-Options	Protezione contro il clickjacking	DENY oppure SAMEORIGIN
Referrer-Policy	Controlla le informazioni referer inviate	no-referrer-when-downgrade
Permissions-Policy	Limita le API del browser accessibili	geolocation=(self), camera=()
Cross-Origin-Opener-Policy	Isola il contesto di navigazione	same-origin
Cross-Origin-Embedder-Policy	Richiede CORP/CORS per le risorse embed	require-corp
Cross-Origin-Resource-Policy	Limita chi può caricare la risorsa	same-site

Configurazione Nginx per impostare gli header di sicurezza:

# Security Headers — Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Permissions-Policy "geolocation=(self), camera=(), microphone=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Embedder-Policy "require-corp" always;

Nota: il parametro always in Nginx garantisce che l’header venga aggiunto anche alle risposte con status code di errore (4xx, 5xx). Senza always, gli header vengono aggiunti solo alle risposte 2xx e 3xx.

Per un audit completo dei security header è possibile utilizzare SecurityHeaders.com, che assegna un punteggio da A+ a F. Per una guida approfondita sulla sicurezza WordPress, incluse le configurazioni server-side, consultare l’articolo dedicato.

---

HTTP header per le performance

Gli HTTP header giocano un ruolo diretto nelle performance di caricamento di un sito. Direttive di caching, compressione, preloading e persistenza della connessione impattano i Core Web Vitals in modo misurabile — in particolare LCP e TTFB.

Cache-Control e caching

L’header Cache-Control è il meccanismo principale per governare la cache HTTP. Le direttive più utilizzate sono max-age (durata in secondi), no-cache (rivalidazione obbligatoria), no-store (nessun caching), public e private.

Per risorse statiche (CSS, JS, immagini) la best practice prevede un max-age lungo (almeno 1 anno: max-age=31536000) combinato con il versioning tramite hash nel nome del file. Per le pagine HTML è preferibile un no-cache o un max-age breve con must-revalidate, per garantire che il contenuto servito sia sempre aggiornato.

La guida completa su come abilitare il browser caching copre tutti gli scenari di configurazione.

Early Hints 103

Lo status code 103 Early Hints, definito nella RFC 8297, permette al server di inviare header Link con direttive preload o preconnect prima che la risposta finale sia pronta. Il browser inizia a scaricare risorse critiche (font, CSS, immagini LCP) mentre il server genera ancora la pagina.

Cloudflare supporta Early Hints in modo nativo. L’impatto sul TTFB percepito può essere significativo, specialmente per pagine con tempi di generazione server-side elevati (pagine dinamiche WordPress non in cache, ad esempio).

Link header (preconnect, preload, dns-prefetch)

L’header HTTP Link consente di suggerire al browser operazioni di caricamento anticipato senza modificare l’HTML della pagina. Le direttive principali sono:

• rel="preload" — scarica la risorsa con priorità alta (font, CSS critici, immagine LCP). Approfondimento: preload
• rel="preconnect" — avvia la connessione TCP+TLS verso un’origine terza (CDN, API esterne). Approfondimento: preconnect e dns-prefetch
• rel="dns-prefetch" — risolve il DNS di un dominio esterno prima che sia necessario

Esempio di Link header in una response Nginx:

Link: </wp-content/themes/theme/style.css>; rel=preload; as=style, <https://fonts.googleapis.com>; rel=preconnect; crossorigin

Queste direttive sono equivalenti ai tag <link> nell’HTML, ma vengono processate dal browser prima ancora di iniziare il parsing del documento — un vantaggio temporale non trascurabile.

Content-Encoding e compressione

L’header Content-Encoding indica la compressione applicata al body della response. I due algoritmi principali sono gzip e Brotli (br). Brotli offre rapporti di compressione migliori del 15-25% rispetto a gzip su risorse testuali (HTML, CSS, JS, JSON), con un impatto diretto sulla riduzione del peso trasferito.

Il browser comunica gli algoritmi supportati tramite il request header Accept-Encoding: gzip, deflate, br. Il server seleziona il migliore disponibile e risponde con Content-Encoding: br (o gzip).

Guida pratica: abilitare gzip su WordPress.

Keep-Alive e Connection

L’header Connection: keep-alive mantiene la connessione TCP aperta dopo il completamento di una request, permettendo di riutilizzarla per le request successive. Questo elimina l’overhead del three-way handshake TCP e del TLS handshake per ogni risorsa.

In HTTP/1.1, keep-alive è il comportamento predefinito. In HTTP/2 e HTTP/3 il concetto è superato dal multiplexing: una singola connessione gestisce più stream in parallelo, rendendo l’header Connection obsoleto.

Approfondimento: keep-alive.

---

Come gestiscono gli header i proxy

Quando una richiesta HTTP transita attraverso un proxy server, un reverse proxy o una CDN, non tutti gli header vengono inoltrati alla destinazione finale. La RFC 9110 distingue tra due categorie:

• End-to-end header — vengono trasmessi fino al destinatario finale (client o origin server). La maggior parte degli header rientra in questa categoria: Cache-Control, Content-Type, Authorization, tutti i security header.
• Hop-by-hop header — sono significativi solo per la singola connessione tra due nodi adiacenti. I proxy li consumano e non li inoltrano.

Gli header hop-by-hop definiti dallo standard sono:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding
• Upgrade

Questa distinzione è rilevante quando si diagnosticano problemi di cache o autenticazione in architetture con CDN o load balancer: un header potrebbe essere presente sulla risposta del server ma assente nella risposta che arriva al client, proprio perché un intermediario lo ha rimosso.

---

Come vedere le intestazioni HTTP

Chrome DevTools

Il metodo più diretto per ispezionare gli header HTTP è il pannello Network dei Chrome DevTools (shortcut: F12 oppure Ctrl+Shift+I).

Procedura:

1. Aprire DevTools e selezionare il tab Network
2. Ricaricare la pagina (Ctrl+R o Cmd+R)
3. Cliccare sulla prima richiesta (il documento HTML) nella lista
4. Nella sezione Headers sono visibili: General (URL, metodo, status code), Response Headers e Request Headers
5. Per visualizzare gli header in formato raw, cliccare su view source accanto a ciascuna sezione

curl da terminale

Il comando curl con il flag -I (o --head) effettua una request HEAD e restituisce solo gli header della response, senza scaricare il body:

curl -I https://www.evemilano.com/

Per visualizzare sia i request header inviati sia i response header ricevuti, il flag -v (verbose) è la scelta migliore:

curl -v -o /dev/null -s https://www.evemilano.com/ 2>&1 | grep -E "^[<>]"

Le righe con > sono i request header, quelle con < i response header. Questo comando è particolarmente utile per diagnosticare problemi di redirect, verificare la presenza di security header, o controllare lo stato della cache lato server.

Strumenti online

Per un’analisi rapida senza aprire il terminale, esistono diversi strumenti web:

• Rex Swain’s HTTP Viewer — visualizza request e response header completi
• AskApache HTTP Headers Tool — analisi header con dettagli su ogni direttiva
• SecurityHeaders.com — audit specifico dei security header con punteggio A+-F
• MDN HTTP Headers Reference — documentazione di riferimento per ogni header standard

---

Configurare HTTP header su Nginx e Apache

La configurazione degli header HTTP avviene a livello di web server. I due server più diffusi — Nginx e Apache — utilizzano sintassi diverse ma concettualmente equivalenti.

Nginx

In Nginx gli header si aggiungono con la direttiva add_header, posizionabile nel blocco http, server o location:

server {
    listen 443 ssl http2;
    server_name www.evemilano.com;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Permissions-Policy "geolocation=(self), camera=(), microphone=()" always;

    # Performance headers — risorse statiche
    location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2|woff)$ {
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header Vary "Accept-Encoding";
    }

    # HTML — cache breve con rivalidazione
    location ~* \.html$ {
        add_header Cache-Control "no-cache, must-revalidate";
    }
}

Nota: in Nginx, le direttive add_header definite in un blocco location sovrascrivono completamente quelle del blocco server padre. Per mantenere i security header anche nei blocchi location, è necessario ripeterli oppure usare il modulo ngx_http_headers_more_module con la direttiva more_set_headers.

Apache (.htaccess)

In Apache gli header si configurano tramite il modulo mod_headers. La configurazione può essere inserita nel file .htaccess nella root del sito o nel virtualhost:

<IfModule mod_headers.c>
    # Security headers
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "no-referrer-when-downgrade"
    Header always set Permissions-Policy "geolocation=(self), camera=(), microphone=()"

    # Cache headers — risorse statiche
    <FilesMatch "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff2|woff)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
        Header set Vary "Accept-Encoding"
    </FilesMatch>

    # HTML — cache breve
    <FilesMatch "\.html$">
        Header set Cache-Control "no-cache, must-revalidate"
    </FilesMatch>
</IfModule>

La differenza tra Header set e Header always set in Apache è analoga al parametro always in Nginx: always set aggiunge l’header anche alle risposte di errore.

---

Domande frequenti

Qual è la differenza tra request header e response header?

I request header vengono inviati dal client (browser) al server e comunicano preferenze, credenziali e contesto della richiesta (es. Accept-Language, Cookie, User-Agent). I response header vengono inviati dal server al client e contengono istruzioni su come gestire la risorsa ricevuta (es. Cache-Control, Content-Type, Set-Cookie). Il flusso è sempre unidirezionale: i request header viaggiano nella richiesta, i response header nella risposta.

Come posso verificare gli HTTP header di un sito?

Esistono tre metodi principali. Da browser: aprire i Chrome DevTools (F12), tab Network, cliccare sulla risorsa e consultare la sezione Headers. Da terminale: eseguire curl -I https://example.com/ per ottenere i response header. Online: usare strumenti come SecurityHeaders.com per un audit dei security header o Rex Swain’s HTTP Viewer per un’analisi completa.

Gli HTTP header influenzano la SEO?

Sì, diversi header hanno un impatto diretto o indiretto sulla SEO. L’header X-Robots-Tag permette di controllare l’indicizzazione di risorse non-HTML (PDF, immagini). Gli header di caching (Cache-Control) e compressione (Content-Encoding) influenzano le performance di caricamento, che sono un fattore di ranking. L’header Strict-Transport-Security garantisce che il sito sia sempre servito via HTTPS, prerequisito per qualsiasi sito moderno. Infine, Location gestisce i redirect, fondamentali durante le migrazioni.

Cos’è l’header HSTS e perché è importante?

HSTS (Strict-Transport-Security) è un response header che istruisce il browser a comunicare con il server esclusivamente via HTTPS per un periodo definito (max-age). Dopo la prima visita, il browser converte automaticamente ogni richiesta HTTP in HTTPS prima ancora di inviarla, eliminando il rischio di SSL stripping (attacco man-in-the-middle che forza il downgrade da HTTPS a HTTP). Con la direttiva preload e l’iscrizione alla HSTS Preload List, la protezione è attiva fin dalla prima visita, senza necessità di una response iniziale.

Come si aggiungono HTTP header personalizzati?

Gli HTTP header personalizzati si configurano a livello di web server. In Nginx si usa la direttiva add_header Nome-Header "valore" always; nel blocco server o location. In Apache si usa Header always set Nome-Header "valore" tramite il modulo mod_headers. In alternativa, su stack WordPress, è possibile aggiungere header via PHP con la funzione header() prima di qualsiasi output, oppure sfruttare le funzionalità del CDN Cloudflare (Transform Rules) per aggiungere o modificare header a livello edge.