Content-Length
L'intestazione Content-Length determina la lunghezza in byte del corpo della richiesta/risposta. Se trascuri di specificare l'intestazione Content-Length, i server HTTP aggiungeranno implicitamente un'intestazione Transfer-Encoding: chunked. L'intestazione Content-Length e Transfer-Encoding non deve essere utilizzata insieme. Il ricevitore non ha idea di quale sia la lunghezza del corpo e non può stimare il tempo di completamento del download. Se si aggiunge un'intestazione Content-Length, assicurarsi che corrisponda all'intero corpo in byte, se non è corretto, il comportamento dei destinatari non è definito.
L'intestazione Content-Length non consente lo streaming, ma è utile per file binari di grandi dimensioni, in cui si desidera supportare la pubblicazione di contenuti parziali. Ciò significa fondamentalmente download ripristinabili, download in pausa, download parziali e download multi-homed. Ciò richiede l'uso di un'intestazione aggiuntiva denominata Range. Questa tecnica è chiamata Byte serving.
Transfer-Encoding
L'uso di Transfer-Encoding: chunked è ciò che permette lo streaming all'interno di una singola richiesta o risposta. Ciò significa che i dati vengono trasmessi in modo frammentato e non influiscono sulla rappresentazione del contenuto.
Ufficialmente un client HTTP ha lo scopo di inviare una richiesta con un campo di intestazione TE che specifica quali tipi di codifiche di trasferimento il client è disposto ad accettare. Questo non viene sempre inviato, tuttavia la maggior parte dei server suppone che i client possano elaborare le codifiche chunked.
La codifica del trasferimento chunked fa un uso migliore delle connessioni TCP permanenti, che HTTP 1.1 assume come valore predefinito.
Content-Encoding
È anche possibile comprimere i dati Chunked o non-chunked. Questo è praticamente fatto tramite l'intestazione Content-Encoding.
Si noti che il Content-Length è uguale alla lunghezza del corpo dopo il Content-Encoding. Ciò significa che se hai gzipato la tua risposta, il calcolo della lunghezza avviene dopo la compressione. Sarà necessario essere in grado di caricare l'intero corpo in memoria se si desidera calcolare la lunghezza (a meno che non si disponga di tali informazioni altrove).
Durante lo streaming utilizzando la codifica Chunked, l'algoritmo di compressione deve supportare anche l'elaborazione in linea. Per fortuna, gzip supporta la compressione del flusso. Credo che il contenuto venga prima compresso e poi tagliato a pezzi. In questo modo, i blocchi vengono ricevuti, quindi decompressi per acquisire il contenuto reale. Se fosse il contrario, otterrai lo stream compresso, e quindi la decompressione ci darebbe dei pezzi. Il che non ha senso.
Una tipica risposta flusso compresso può avere queste intestazioni:
Content-Type: text/html
Content-Encoding: gzip
Transfer-Encoding: chunked
semanticamente l'utilizzo di Content-Encoding indica una "end to end" schema di codifica, il che significa che solo il cliente finale o il server finale si suppone per decodificare il soddisfare. I proxy nel mezzo non sono autorizzati a decodificare il contenuto.
Se si desidera consentire ai proxy nel mezzo di decodificare il contenuto, l'intestazione corretta da utilizzare è infatti l'intestazione Transfer-Encoding. Se la richiesta HTTP possedeva un'intestazione TE: gzip chunked, è legale rispondere con Transfer-Encoding: gzip chunked.
Tuttavia, questo è molto raramente supportato. Quindi dovresti usare solo Content-Encoding per la compressione adesso.
Chunked vs Store & Forward
E 'un dato che il contenuto è statico e la sua lunghezza è noto a priori? In caso contrario, Chunked sarebbe molto più veloce per file di grandi dimensioni. –