There also is no way, in current HTTP specs, for a Server to distinguish between "Content-encoding" and "Transfer-encoding" as far as what the client really means it can/can't do.
When a User-Agent says "Accept-encoding: xxxx" a Server can only assume that it means it can handle the 'xxxx' encoding for EITHER "Content-encoding:" OR "Transfer-encoding:". There's just no way to tell the difference. Same HTTP request field is supposed to be good for BOTH 'Transfer' and 'Content' encoding.
My reading of RFC 2616 is that Accept-encoding is only for content-codings. Clients should indicate their ability to handle transfer-codings via TE.
Content-Encoding: gzip together with Transfer-Encoding: chunked
or simply...
Transfer-Encoding: gzip, chunked.
It should make no difference to the 'receiver'.
Well, not if the receiver is a caching proxy...
As far as I understand it, mod_deflate's practice of returning Content-encoding: gzip but using Transfer-encoding: gzip semantics (e.g. conditionally compressing a resource and using the same ETag for both the compressed and non-compressed forms of that resource) is potentially poisonous to proxies that handle Range.
