Il codice di stato HTTP 100 Continue è una risposta informativa con cui il server comunica al client che la prima parte della richiesta è stata ricevuta correttamente e che può continuare inviando il corpo della richiesta.

Viene utilizzato principalmente quando un browser, un’applicazione o un altro client deve trasmettere una quantità significativa di dati, come un file, un backup, un video oppure una richiesta API particolarmente grande.

A differenza dei codici HTTP definitivi, come 200 OK, 404 Not Found o 500 Internal Server Error, il codice 100 non conclude la comunicazione. Il server invierà successivamente una seconda risposta contenente lo stato definitivo dell’operazione.

Che cosa significa HTTP 100 Continue?

Quando un client deve inviare una richiesta composta da intestazioni e contenuto, può chiedere preventivamente al server se è disposto ad accettarla. Per farlo utilizza generalmente l’intestazione:

Expect: 100-continue

Il client invia prima le intestazioni HTTP, senza trasmettere immediatamente tutto il corpo della richiesta. Il server esamina informazioni come metodo, autorizzazione, tipo di contenuto e dimensione dichiarata.

Se non rileva problemi preliminari, risponde:

HTTP/1.1 100 Continue

Dopo aver ricevuto questa conferma, il client può inviare il corpo completo della richiesta. Terminata l’elaborazione, il server restituisce una risposta definitiva, ad esempio 200 OK, 201 Created oppure un codice di errore.

HTTP 100 non è un errore

Il codice 100 appartiene alla classe delle risposte 1xx informative. Non segnala quindi un errore del sito, del server o del client.

Il messaggio indica soltanto che la comunicazione è ancora in corso. La risposta definitiva arriverà dopo l’invio e l’elaborazione del contenuto.

• • 1xx: risposta informativa e provvisoria;

• • 2xx: operazione completata con successo;

• • 3xx: reindirizzamento;

• • 4xx: problema nella richiesta del client;

• • 5xx: errore durante l’elaborazione sul server.

Come funziona una richiesta con 100 Continue

La comunicazione può essere riassunta in cinque passaggi:

1. 1. Il client prepara una richiesta contenente un corpo, come un caricamento tramite POST o PUT.

1. 1. Invia le intestazioni aggiungendo Expect: 100-continue.

1. 1. Il server esamina le intestazioni prima di ricevere il contenuto completo.

1. 1. Se la richiesta può proseguire, il server restituisce 100 Continue.

1. 1. Il client invia il corpo e attende la risposta definitiva.

Esempio di richiesta HTTP

Il seguente esempio rappresenta l’inizio del caricamento di un file:

POST /upload HTTP/1.1\nHost: esempio.it\nContent-Type: application/octet-stream\nContent-Length: 52428800\nExpect: 100-continue

Il client dichiara di voler inviare un contenuto di circa 50 MB, ma attende prima il consenso del server.

Se la richiesta può essere accettata, il server risponde:

HTTP/1.1 100 Continue

\n\n

A questo punto il client trasmette il file. Completato il caricamento, il server può restituire, per esempio:

HTTP/1.1 201 Created\nContent-Type: application/json\n\n{"status":"success","message":"File caricato"}

Quando viene utilizzato il codice 100 Continue?

Il codice HTTP 100 è utile soprattutto nelle richieste che prevedono l’invio di un corpo voluminoso:

• • caricamento di video, immagini o archivi ZIP;

• • upload di backup;

• • invio di grandi documenti;

• • importazione di cataloghi tramite API;

• • richieste POST o PUT con molti dati;

• • trasferimento di pacchetti verso un servizio remoto;

• • comunicazioni tra applicazioni e sistemi di archiviazione.

Per richieste molto piccole, il controllo preliminare può risultare meno vantaggioso, perché introduce un ulteriore scambio tra client e server.

Perché non inviare immediatamente il contenuto?

Immaginiamo che un client debba caricare un file di diversi gigabyte, ma che il server sia destinato a rifiutarlo perché:

• • l’utente non è autenticato;

• • non possiede i permessi necessari;

• • il formato non è supportato;

• • la dimensione supera il limite consentito;

• • la risorsa non esiste;

• • il server richiede una condizione aggiuntiva.

Senza il meccanismo 100 Continue, il client potrebbe trasferire inutilmente una grande quantità di dati prima di ricevere il rifiuto. Il controllo preventivo permette al server di interrompere la procedura prima dell’upload.

Il server può rifiutare subito la richiesta?

Sì. Se le intestazioni mostrano già un problema, il server può inviare direttamente una risposta definitiva senza restituire 100 Continue.

Alcuni esempi possibili sono:

• • 401 Unauthorized se manca l’autenticazione;

• • 403 Forbidden se l’utente non dispone dei permessi;

• • 404 Not Found se l’endpoint non esiste;

• • 405 Method Not Allowed se il metodo non è accettato;

• • 413 Content Too Large se il contenuto dichiarato supera il limite;

• • 417 Expectation Failed se il server non può soddisfare l’aspettativa indicata.

In questi casi il client non dovrebbe inviare il corpo della richiesta.

Differenza tra 100 Continue e 200 OK

I codici 100 e 200 hanno funzioni completamente differenti.

Che cosa succede se il server non risponde?

Un client non dovrebbe attendere indefinitamente la risposta 100 Continue. Solitamente applica un breve timeout e, se non riceve una risposta informativa o definitiva, può iniziare comunque a inviare il contenuto.

Il comportamento preciso dipende dalla libreria HTTP, dal programma utilizzato e dalla configurazione del client. Un server o un proxy che gestisce male l’intestazione Expect può quindi introdurre ritardi prima dell’upload.

Problemi con proxy, CDN e reverse proxy

La comunicazione può attraversare componenti intermedi come CDN, firewall, bilanciatori, proxy e reverse proxy. Questi sistemi devono gestire correttamente sia l’intestazione Expect sia le risposte informative 1xx.

Una configurazione non corretta può causare:

• • attese prima dell’invio del corpo;

• • timeout durante l’upload;

• • risposte 417 inattese;

• • connessioni chiuse prematuramente;

• • duplicazione o perdita delle risposte informative;

• • problemi durante il caricamento di file di grandi dimensioni.

Quando un upload funziona collegandosi direttamente al server ma fallisce passando attraverso un proxy o una CDN, è utile controllare anche la gestione di Expect: 100-continue.

Come testare 100 Continue con cURL

È possibile inviare esplicitamente l’intestazione utilizzando cURL:

curl -v \\n  -H "Expect: 100-continue" \\n  -H "Content-Type: application/octet-stream" \\n  --data-binary "@file.zip" \\n  https://esempio.it/upload

L’opzione -v mostra i dettagli della comunicazione. Se il server supporta il meccanismo, nell’output dovrebbe comparire una risposta simile:

< HTTP/1.1 100 Continue

Successivamente verrà visualizzata la risposta definitiva del server.

HTTP 100 e WordPress

In un normale sito WordPress il codice 100 Continue raramente viene mostrato all’utente nel browser. Può però comparire nei log o durante operazioni tecniche come:

• caricamento di file nella Libreria media;

• • importazione di contenuti;

• • installazione di temi o plugin;

• • municazioni con API REST;

• • backup trasferiti verso servizi esterni;

• • sincronizzazione di cataloghi e prodotti;

• • upload gestiti da plugin personalizzati.

Se WordPress mostra un errore durante un caricamento, il codice 100 non è normalmente la causa diretta. Bisogna controllare la risposta definitiva, i log PHP, i limiti di upload, la configurazione del web server e gli eventuali proxy intermedi.

Il codice 100 influisce sulla SEO?

Il codice HTTP 100 non rappresenta una risposta definitiva indicizzabile e non viene utilizzato per comunicare ai motori di ricerca lo stato finale di una pagina.

Dal punto di vista SEO contano soprattutto la risposta conclusiva e il contenuto ricevuto dal crawler. Una pagina deve quindi terminare con il codice appropriato, come 200 per una risorsa disponibile, 301 per un trasferimento permanente oppure 404 o 410 per una risorsa assente.

HTTP 100 Continue è una risposta provvisoria che autorizza il client a proseguire con l’invio del corpo della richiesta. È particolarmente utile nei caricamenti di grandi dimensioni perché permette al server di esaminare prima le intestazioni e rifiutare rapidamente richieste non valide.

Non indica né un successo definitivo né un errore. Dopo il codice 100 deve arrivare una risposta finale che comunichi l’esito reale dell’operazione.

In caso di problemi con upload, API o trasferimenti di file, bisogna quindi esaminare l’intera sequenza HTTP e non fermarsi alla risposta informativa 100 Continue.