PROTOCOLLO DI TRASFERIMENTO FILE (FTP)

La codifica del trasferimento in blocchi è un meccanismo di trasferimento dei dati in streaming disponibile nella versione 1.1 del protocollo HTTP ( Hypertext Transfer Protocol ). Nella codifica del trasferimento in blocchi, il flusso di dati è diviso in una serie di "blocchi" non sovrapposti. I pezzi vengono inviati e ricevuti indipendentemente l'uno dall'altro. Nessuna conoscenza del flusso di dati al di fuori del blocco attualmente in fase di elaborazione è necessaria sia per il mittente che per il destinatario in un dato momento.

Ogni blocco è preceduto dalla sua dimensione in byte. La trasmissione termina quando viene ricevuto un blocco di lunghezza zero. La parola chiave chunked nell'intestazione Transfer-Encoding viene utilizzata per indicare il trasferimento in blocchi.

Una prima forma di codifica del trasferimento in blocchi è stata proposta nel 1994.  La codifica del trasferimento in blocchi non è supportata in HTTP / 2 , che fornisce i propri meccanismi per lo streaming dei dati. 

Razionale

L'introduzione della codifica in blocchi ha fornito diversi vantaggi:

• La codifica di trasferimento in blocchi consente a un server di mantenere una connessione persistente HTTP per il contenuto generato dinamicamente. In questo caso, l'intestazione HTTP Content-Length non può essere utilizzata per delimitare il contenuto e la successiva richiesta / risposta HTTP, poiché la dimensione del contenuto non è ancora nota. La codifica in blocchi ha il vantaggio che non è necessario generare il contenuto completo prima di scrivere l'intestazione, in quanto consente lo streaming del contenuto come blocchi e segnalando esplicitamente la fine del contenuto, rendendo la connessione disponibile per la successiva richiesta / risposta HTTP.
• La codifica in blocchi consente al mittente di inviare campi di intestazione aggiuntivi dopo il corpo del messaggio. Ciò è importante nei casi in cui i valori di un campo non possono essere conosciuti fino a quando il contenuto non è stato prodotto, ad esempio quando il contenuto del messaggio deve essere firmato digitalmente. Senza la codifica in blocchi, il mittente dovrebbe bufferizzare il contenuto fino al completamento per calcolare un valore di campo e inviarlo prima del contenuto.

Applicabilità 

Per la versione 1.1 del protocollo HTTP, il meccanismo di trasferimento in blocchi è considerato sempre e comunque accettabile, anche se non elencato nel TE(codifica di trasferimento) campo di intestazione della richiesta e, se utilizzato con altri meccanismi di trasferimento, deve essere sempre applicato per ultimo ai dati trasferiti e mai più di una volta. Questo metodo di codifica del trasferimento consente inoltre di inviare campi di intestazione dell'entità aggiuntivi dopo l'ultimo blocco se il client ha specificato il parametro "trailer" come argomento del campo TE. Il server di origine della risposta può anche decidere di inviare ulteriori trailer di entità anche se il client non ha specificato l'opzione "trailer" nel campo della richiesta TE, ma solo se i metadati sono facoltativi (ovvero il client può utilizzare l'entità ricevuta senza di essi ). Ogni volta che vengono utilizzati i trailer, il server dovrebbe elencare i loro nomi nel campo dell'intestazione Trailer; tre tipi di campo di intestazione sono specificamente vietati per apparire come un campo di rimorchio: , Lunghezza del contenuto e trailer .

Formato 

Se un campo Transfer-Encoding con un valore di " chunked " è specificato in un messaggio HTTP (sia una richiesta inviata da un client o la risposta dal server), il corpo del messaggio è costituito da un numero non specificato di blocchi, un chunk, trailer e una sequenza CRLF finale (cioè ritorno a capo seguito da avanzamento riga ).

Ogni blocco inizia con il numero di ottetti dei dati che incorpora espresso come un numero esadecimale in ASCII seguito da parametri opzionali ( estensione del blocco ) e una sequenza CRLF di terminazione, seguito dai dati del blocco. Il blocco viene terminato da CRLF.

Se vengono fornite estensioni del blocco, la dimensione del blocco viene terminata da un punto e virgola e seguita dai parametri, ciascuno delimitato anche da punto e virgola. Ogni parametro è codificato come un nome di estensione seguito da un segno di uguale e da un valore facoltativi. Questi parametri possono essere utilizzati per un digest del messaggio in esecuzione o una firma digitale o per indicare, ad esempio, l'avanzamento stimato del trasferimento.

Il blocco di terminazione è un blocco regolare, con l'eccezione che la sua lunghezza è zero. È seguito dal trailer, che consiste in una sequenza (possibilmente vuota) di campi di intestazione dell'entità. Normalmente, tali campi di intestazione vengono inviati nell'intestazione del messaggio; tuttavia, potrebbe essere più efficiente determinarli dopo l'elaborazione dell'intera entità del messaggio. In tal caso, è utile inviare quelle intestazioni nel trailer.

I campi di intestazione che regolano l'uso dei trailer sono TE (utilizzato nelle richieste) e Trailers (utilizzato nelle risposte).

Utilizzare con la compressione 

I server HTTP utilizzano spesso la compressione per ottimizzare la trasmissione, ad esempio con Content-Encoding: gzip o Content-Encoding: deflate . Se sono abilitate sia la compressione che la codifica in blocchi, il flusso di contenuto viene prima compresso, quindi suddiviso in blocchi; quindi la codifica del blocco stesso non viene compressa ei dati in ogni blocco non vengono compressi individualmente. L'endpoint remoto quindi decodifica il flusso concatenando i blocchi e decomprimendo il risultato.

Esempio 

Dati codificati 

Nell'esempio seguente, vengono mostrati tre blocchi di lunghezza 4, 6 e 14 ("E" esadecimale). La dimensione del blocco viene trasferita come numero esadecimale seguito da \ r \ n come separatore di riga, seguito da un blocco di dati della dimensione specificata.

4\r\n (bytes to send)
Wiki\r\n (data)

6\r\n (bytes to send)
pedia \r\n (data)

E\r\n (bytes to send)
in \r\n
\r\n
chunks.\r\n (data)

0\r\n (final byte - 0)
\r\n (end message)

Nota: la dimensione del blocco indica la dimensione dei dati del blocco ed esclude il CRLF finale ("\ r \ n"). In questo particolare esempio, il CRLF che segue "in" viene conteggiato come due ottetti rispetto alla dimensione del blocco di 0xE (14). Anche i CRLF nella propria riga vengono conteggiati come due ottetti rispetto alla dimensione del blocco. Il carattere punto alla fine di "blocchi" è il quattordicesimo carattere, quindi è l'ultimo carattere di dati in quel blocco. Il CRLF che segue il punto è il CRLF finale, quindi non viene conteggiato per la dimensione del blocco di 0xE.