Content-Encoding vs Transfer Encoding in HTTP

Question

I have a question on usage of Content-Encoding and Transfer-Encoding:

Please let me know if my below understanding is right:

Client in its request can specify which encoding types it is willing to accept using accept-encoding header. So, if Server wishes to encode the message before transmission, eg. gzip, it can zip the entity (content) and add content-encoding: gzip and send across the HTTP response. On reception, client can receive and decompress and parse the entity.

In case of Transfer Encoding, Client may specify what kind of encoding it is willing to accept and perform its action on fly. i.e. if Client sends a TE: gzip; q=1, it means that if Server wishes, it can send a 200 OK with Transfer-Encoding: gzip and as it tries sending the stream, it can compress and send across, and client upon receiving the content, can decompress on fly and perform its parsing.

Is my understanding right here? Please comment.

Also, what is the basic advantage of compressing the entity on fly vs compressing the entity first and then transmitting it across? Is transfer-encoding valid only for chunked responses as we do not know the size of the entity before transmission?

Answer 1

The difference really is not about on-the-fly or not -- Content-Encoding can be both pre-computed and on the fly.

The differences are:

• Transfer Encoding is hop-by-hop, not end-to-end
• Transfer Encodings other than "chunked" (sadly) aren't implemented in practice
• Transfer Encoding is on the message layer, Content Encoding on the payload layer
• Using Content Encoding affects entity tags etc.

See http://greenbytes.de/tech/webdav/rfc7230.html#transfer.codings and http://greenbytes.de/tech/webdav/rfc7231.html#data.encoding.