> transfer-coding

Transfer codings are meant to be hop-by-hop, but we'd prefer if
intermediate proxies just passed our messages through without
caching.  Can we achieve this?

draft-mogul-*-02 says it's not clear whether this should be a
transfer-encoding or a content-encoding.  It seems to fall in the
middle: it is neither hop-by-hop nor an inherent property of the
entity. 

Should cope with q=0, which means `no, I'm not having that one', and
(I guess) prioritize on qvalue.

 > non-rsync proxies

We have to make sure that proxies that don't understand rsync won't
cache the encoded response.  [dc-report] talks about this a bit.

   The TE request-header field indicates what extension transfer-codings
   it is willing to accept in the response and whether or not it is
   willing to accept trailer fields in a chunked transfer-coding.

   The TE header field only applies to the immediate connection.

rfc2616 seems to indicate that we can't pass unknown transfer-codings
through proxies, because

   A server which receives an entity-body with a transfer-coding it does
   not understand SHOULD return 501 (Unimplemented), and close the
   connection. A server MUST NOT send transfer-codings to an HTTP/1.0
   client.

Since the definition of `server' includes proxies, this means that
they won't allow this.