Codifica trasferimento: gzip vs. codifica contenuto: gzip

Qual è lo stato attuale delle cose quando si tratta di fare o meno

Transfer-Encoding: gzip

o a

Content-Encoding: gzip

quando voglio consentire ai client con una larghezza di banda limitata, ad esempio, di segnalare la loro disponibilità ad accettare una risposta compressa e il server ha l'ultima parola se comprimere o meno .

Quest'ultimo è ciò che, ad esempio, mod_deflate e IIS di Apache fanno, se si lascia che si occupi della compressione. A seconda della dimensione del contenuto da comprimere, farà l'addizionale Transfer-Encoding: chunked.

Includerà anche un Vary: Accept-Encoding, che già accenna al problema. Content-Encodingsembra essere parte dell'entità, quindi modificare gli Content-Encodingimporti in una modifica dell'entità, ovvero Accept-Encodingun'intestazione diversa significa, ad esempio, che una cache non può utilizzare la sua versione memorizzata nella cache dell'entità altrimenti identica.

C'è una risposta definitiva su questo che mi sono perso (e che non è sepolta all'interno di un messaggio in un lungo thread in qualche newsgroup di Apache)?

La mia impressione attuale è:

• Transfer-Encoding sarebbe infatti il ​​modo giusto per fare ciò che viene fatto principalmente con Content-Encoding da implementazioni di server e client esistenti
• La codifica del contenuto, a causa delle sue implicazioni semantiche, comporta un paio di problemi (cosa dovrebbe fare il server ETagquando comprime in modo trasparente una risposta?)
• Il motivo è chicken'n'egg: i browser non lo supportano perché i server no perché i browser no

Quindi presumo che il modo giusto sarebbe un Transfer-Encoding: gzip(o, se anche un altro pezzo del corpo, diventerebbe Transfer-Encoding: gzip, chunked ). E non c'è motivo di toccare Varyo ETago qualsiasi altra intestazione in quel caso poiché è una cosa a livello di trasporto.

Per ora non mi interessa molto del 'hop-by-hop' Transfer-Encoding, qualcosa di cui gli altri sembrano preoccuparsi prima di tutto, perché i proxy potrebbero decomprimersi e inoltrare non compressi al client. Tuttavia, i proxy potrebbero altrettanto bene inoltrarlo così com'è (compresso), se la richiesta originale ha l' Accept-Encodingintestazione corretta , che nel caso di tutti i browser che conosco è un dato di fatto.

A proposito, questo problema ha almeno un decennio, vedere ad esempio https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

Ogni chiarimento in merito sarà gradito. Sia in termini di ciò che è considerato conforme agli standard che di ciò che è considerato pratico. Ad esempio, le librerie client HTTP che supportano solo la "Content-Encoding" trasparente sarebbero un argomento contro la praticità.

Citando Roy T. Fielding , uno degli autori della RFC 2616:

la modifica al volo della codifica del contenuto in modo incoerente (né "mai" né "sempre) rende impossibile gestire correttamente le richieste successive riguardanti quel contenuto (ad es. PUT o GET condizionale). Questo è, ovviamente, il motivo per cui eseguire la codifica dei contenuti al volo è un'idea stupida e perché ho aggiunto Transfer-Encoding a HTTP come modo corretto per eseguire la codifica al volo senza modificare la risorsa.

Fonte: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

In altre parole: non eseguire la codifica dei contenuti al volo , usa invece la codifica del trasferimento!

Modifica: Cioè, a meno che tu non voglia servire contenuto gzippato a client che comprendono solo Content-Encoding . Che, sfortunatamente, sembra essere la maggior parte di loro. Ma tieni presente che lasci i regni delle specifiche e potresti incorrere in problemi come quello menzionato da Fielding e altri, ad esempio quando sono coinvolti i proxy di cache.

L' utilizzo corretto , come definito nella RFC 2616 e effettivamente implementato in natura, è che il client invii Accept-Encodingun'intestazione di richiesta (il client può specificare più codifiche). Il server può quindi, e solo allora, codificare la risposta in base alle codifiche supportate dal client (se i dati del file non sono già memorizzati in quella codifica), indicare nell'intestazione della Content-Encodingrisposta quale codifica viene utilizzata. Il client può quindi leggere i dati dal socket in base a Transfer-Encoding(ie, chunked) e quindi decodificarli in base a Content-Encoding(ie:) gzip.

Quindi, nel tuo caso, il client invierà Accept-Encoding: gzipun'intestazione di richiesta, quindi il server potrebbe decidere di comprimere (se non lo è già) e inviare un'intestazione di risposta Content-Encoding: gzipe facoltativamente Transfer-Encoding: chunked.

E sì, l' Transfer-Encodingintestazione può essere utilizzata nelle richieste, ma solo per HTTP 1.1, che richiede che le implementazioni client e server supportino la chunkedcodifica in entrambe le direzioni.

ETagidentifica in modo univoco i dati delle risorse sul server, non i dati effettivamente trasmessi. Se una determinata risorsa URL cambia il suo ETagvalore, significa che i dati lato server per quella risorsa sono cambiati.