Timeline for Why Content-Encoding gzip rather than Transfer-Encoding gzip
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2017 at 9:56 | comment | added | Jon Hanna | @KentonVarda at the level of the protocol the difference between "static" and "on-the-fly" simply doesn't exist, so yes it is an implementation detail. You're correct that it can have that have that effect on byte-identity (though you could still use no, or a weak ETag) though it need not. That's another reason to favour TE in such cases, though in no way does it make CE better. | |
| Jan 18, 2017 at 2:35 | comment | added | Kenton Varda | @JonHanna It's not an implementation detail. The question to ask is: are the bytes exactly the same, or merely equivalent. TE does not imply that the (compressed) bytes are exactly the same as served by any other request. CE does (assuming matching non-weak ETag). This is important for caches and especially important when serving range requests. If you are compressing on-the-fly, you can't really guarantee identical bytes; e.g. an update to the compression code might change things. | |
| Jan 17, 2017 at 9:52 | comment | added | Jon Hanna | @KentonVarda the difference between static and on-the-fly is an implementation detail. The distinction is one that simply isn't present as far as the transfer protocol goes. | |
| Jan 17, 2017 at 6:24 | comment | added | Kenton Varda | I have to disagree with the opinion that TE is always preferred. TE makes sense when you are compressing on-the-fly. CE makes sense when you're serving already-compressed content directly from storage. For your textual static content (JS, CSS, SVG, maybe HTML), you should have already-compressed copies to serve; you don't want to re-compress them on every request. In that case use CE. Similarly, caches benefit from storing the compressed content if it will be requested repeatedly. Ideally you use TE only for dynamic content -- because that's the only content compressed on-the-fly. | |
| May 25, 2015 at 14:46 | comment | added | Jon Hanna |
@CMCDragonkai sorry, yes: gzip, chunked. The lack of comma above was just a typo, and it is required. For the reasons I give though, you might find just using Content-Encoding for the gzip works better in practice.
|
|
| May 25, 2015 at 14:02 | comment | added | CMCDragonkai |
I checked some place else and it seemed that the correct notation is gzip, chunked. Does it need a comma?
|
|
| May 25, 2015 at 13:25 | comment | added | Jon Hanna |
@CMCDragonkai gzip chunked to indicate that first GZip had been applied, and then chunked. (Which incidentally is a rule in itself; if chunked is applied along with another encoding, it must be the last applied, though it doesn't really make sense to do anything else anyway).
|
|
| May 25, 2015 at 11:24 | comment | added | CMCDragonkai |
If you wanted to gzip and chunk encoding the content and you wanted to use Transfer-Encoding and not Content-Encoding. What would you put in the Transfer-Encoding header? Would it be gzip or chunked or something like gzip chunked?
|
|
| Sep 9, 2014 at 4:30 | vote | accept | Jyotirmoy Bhattacharya | ||
| Sep 13, 2012 at 22:03 | review | First posts | |||
| Oct 13, 2012 at 11:23 | |||||
| Sep 13, 2012 at 11:23 | history | answered | Jon Hanna | CC BY-SA 3.0 |