Codice di Stato HTTP 100-Continue

Approfondimenti di uno codice di stato interessante e a molti sconosciuto.

Mi sono imbattuto negli ultimi mesi con un API Gateway e una serie di webapi che non ne volevano sapere di andare, trovandomi di fronte al 100 Continue ed errori di Idle Timeout...

Quindi ho approfondito la quesione.

Codice di Stato "100 Continue"

Il codice di stato HTTP "100 Continue" serve principalmente come metodo di ottimizzazione nelle comunicazioni client-server. La sua funzione principale è quella di evitare lo spreco di risorse di rete quando un client sta per inviare una grande quantità di dati (entità) al server.

Ecco come funziona:

● Il client invia prima l'header della richiesta, includendo informazioni sull'entità come la dimensione (Content-Length). In questo modo, il server può valutare se è in grado di accettare l'entità prima che venga inviata.

● Il server, se è disposto ad accettare l'entità, risponde con "100 Continue". Questo segnale indica al client che può procedere con l'invio dei dati.

● Se il server non può accettare l'entità, risponde con un codice di stato appropriato (es. 413 Payload Too Large). In questo modo, il client evita di inviare dati che verrebbero rifiutati, risparmiando tempo e risorse di rete.

L'utilizzo di "100 Continue" è particolarmente utile nei seguenti scenari:

● Upload di file di grandi dimensioni: Il client può verificare se il server è in grado di gestire il file prima di iniziare l'upload.

● Richieste con entità complesse: Il server può valutare l'accettabilità dell'entità prima di elaborarla.

● Situazioni in cui il server potrebbe rifiutare l'entità: Ad esempio, se l'utente non è autorizzato o se il tipo di richiesta (es. PUT invece di POST) è errato.

In sintesi, il codice "100 Continue" introduce un meccanismo di "handshake" tra client e server, consentendo una comunicazione più efficiente ed evitando lo spreco di risorse in caso di entità di grandi dimensioni o potenziali rifiuti da parte del server.

Differenze nei comportamenti di client, server e proxy durante un processo "100 Continue"

Client

Il client deve impostare Expect: 100-continue nelle intestazioni della richiesta se si aspetta di ricevere una risposta "100 Continue". Questo segnala al server che il client ha un corpo dell'entità da inviare ma desidera prima verificare se il server lo accetterà.

Se non c'è un'entità da inviare, il client non deve impostare Expect: 100-continue. In caso contrario, ciò indurrebbe erroneamente il server a pensare che stia per ricevere un'entità.

Il client non dovrebbe attendere all'infinito "100 Continue". Se il server va in timeout, il client può inviare direttamente l'entità.

Dopo aver inviato l'entità, il client dovrebbe ignorare ogni "100 Continue".

Se il client riceve "417 Expectation Failed", ciò non significa che il server si rifiuta di ricevere l'entità. Significa semplicemente che la catena di risposte non supporta l'intestazione Expect, ad esempio un server o proxy HTTP/1.0. In questi casi, il client dovrebbe semplicemente ripetere la richiesta, ma questa volta senza Expect: 100-continue.

Server

Il server deve ignorare Expect: 100-continue in una richiesta HTTP/1.0.

Se le intestazioni della richiesta non contengono Expect: 100-continue, il server non deve inviare "100 Continue".

Se l'entità viene ricevuta prima che il server possa controllare e rispondere alle intestazioni, può omettere "100 Continue" e inviare direttamente la risposta finale.

Al ricevimento di una richiesta con Expect: 100-continue:

Se l'entità è accettabile, il server deve rispondere con "100 Continue" per incoraggiare il client a inviare l'entità.

In caso contrario, il server deve rispondere con un codice di stato appropriato come risposta finale, ad esempio "401 Unauthorized" se un utente sconosciuto tenta di caricare file o "413 Payload Too Large" se l'entità è troppo grande per essere elaborata.

Proxy

Al ricevimento di una richiesta con Expect: 100-continue da un client:

Se il proxy sa che il server supporta solo HTTP/1.0 o versioni precedenti, deve restituire "100 Continue" o "417 Expectation Failed".

In caso contrario, il proxy deve inoltrare questa richiesta insieme a Expect: 100-continue.

Al ricevimento di una risposta "100 Continue" da un server:

Se Expect: 100-continue è stato aggiunto dal proxy stesso per conto del client, non deve inoltrare questa risposta al client. Dovrebbe decidere autonomamente cosa fare con la risposta.

In caso contrario, deve inoltrare questa risposta al client, anche se il client supporta solo HTTP/1.0 o versioni precedenti.

Problemi di compatibilità

Tutti i codici di stato 1xx condividono alcuni problemi di compatibilità, poiché non sono stati introdotti fino a HTTP/1.1. Pertanto, server, client e proxy devono attenersi a una serie di principi:

Server: Non deve inviare risposte 1xx ai client HTTP/1.0.

Client: Deve essere in grado di analizzare le risposte 1xx prima della risposta finale, anche se inaspettate.

Proxy: Deve inoltrare le risposte 1xx, ad eccezione di quelle richieste dal proxy stesso.

CONCLUSIONE: In sostanza, il processo "100 Continue" è un meccanismo che consente a un client di verificare se un server accetterà un'entità di grandi dimensioni prima di inviarla, risparmiando potenzialmente larghezza di banda e risorse se il server la rifiuta. Client, server e proxy hanno ruoli e comportamenti specifici in questo processo per garantire che funzioni correttamente.