rfc2616 - Content-Encoding vs Transfer Encoding in HTTP -

i have question on usage of content-encoding , transfer-encoding:

please let me know if below understanding right:

client in request can specify encoding types willing accept using accept-encoding header. so, if server wishes encode message before transmission, eg. gzip, can zip entity (content) , add content-encoding: gzip , send across http response. on reception, client can receive , decompress , parse entity.

in case of transfer encoding, client may specify kind of encoding willing accept , perform action on fly. i.e. if client sends te: gzip; q=1, means if server wishes, can send 200 ok transfer-encoding: gzip , tries sending stream, can compress , send across, , client upon receiving content, can decompress on fly , perform parsing.

is understanding right here? please comment.

also, basic advantage of compressing entity on fly vs compressing entity first , transmitting across? transfer-encoding valid chunked responses not know size of entity before transmission?

the difference not on-the-fly or not -- content-encoding can both pre-computed , on fly.

the differences are:

• transfer encoding hop-by-hop, not end-to-end
• transfer encodings other "chunked" (sadly) aren't implemented in practice
• transfer encoding on message layer, content encoding on payload layer
• using content encoding affects entity tags etc.

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