[28] 実体を (媒体型や文字符号化とは別に) 符号化する仕組みとして、 HTTP には内容符号化と転送符号化、MIME には内容転送符号化があります。
[29] 内容符号化は、本来の意味的には転送される実体の本質的な一部となった符号化を表します。 例えば、 gzip 圧縮されたファイルを転送する場合、内容符号化が gzip であるといえます。一方転送符号化は、転送時の都合上の一時的な符号化を表します。 HTTP/1.1 では実体本体全体の長さがわからなくても少しずつ転送を繰り返す chunked 符号化の仕組みがありますが、こちらは転送符号化です。ただし、 歴史的理由により本来転送符号化であるものが内容符号化によって転送されたり、 内容符号化であるものが転送符号化であったかのように扱われたりすることがあります。
HTTP、RTSP、SIP では内容符号化の識別に Content-Encoding:
頭欄、転送符号化の識別に Transfer-Encoding: 頭欄を使います。
内容折衝のために内容符号化では Accept-Encoding: 頭欄、
転送符号化では TE: 頭欄が用いられます。
[37] 内容転送符号化は、実体の転送時の都合上の一時的な符号化を表します。
その意味で HTTP の転送符号化に近い概念です。 MIME
では内容転送符号化の識別に Content-Transfer-Encoding:
頭欄を使います。
[1] HTTP には更に実現値操作という概念も提案されていました。
[3] 内容符号化、転送符号化、内容転送符号化の名前を表す値はいずれも大文字・小文字を区別しないとされています。
[31] 内容符号化と転送符号化で使える値の集合は別々ですが、 重なりがあって、実際上も内容符号化と転送符号化が混用されています。
[32] また、本来 MIME の内容転送符号化であり、 HTTP では意味を成さない値も内容符号化として誤用されていることがあります。
[4] 内容符号化、転送符号化、内容転送符号化のいずれでも、例によって
x- から始まる値は私用のために予約されています。
[30] ただし、 RFC 1945 HTTP/1.0 の定義だけは変則的で、
x-gzip のような x-
がついた名前の方だけが規定に含まれています。
[24] 以前は IANAREG には転送符号化として chunked
しか登録されておらず、 RFC 2616 で Transfer-Encoding:
欄でも転送符号化として指定できるよう拡張された (RFC 2068 ではそうなっていなかった)
gzip などの値はありませんでした。
[36]
もしかすると単なる転送のための圧縮は内容符号化ではなく転送符号化を使うべし、という意思が働いているのかもしれません...
(そうすれば、ダウンロードした *.gz ファイルが勝手に展開されている、という問題は防げるようになるでしょうし。)
[11] mod_gzip とか流行ってるわけですが、ほんとは転送上の圧縮は Content-Encoding じゃなくて Transfar-Encoding 使うべきじゃないんですかね。もっとも、主要 UA で対応しているのは Opera だけという有様ですが。。。 (一方内容符号化はほとんどの主要 UA で扱えるから。。。)
[15]
ファイルとして保存する時に UA が Content-Encoding (特に gzip を展開してしまい、利用者は圧縮したものを受取ったつもりでいて混乱するという問題が多発していまして、
内容折衝するのでもなければ Content-Encoding は使うべきではないという意見すらありますね。
本当は保存時に展開するかどうかを UA が利用者に尋ねるのが良いのでしょう。
転送のためだけの圧縮も、 >>11 の言うように Content-Encoding は使わずに Transfer-Encoding にした方がいいでしょう。 Transfer-Encoding に gzip などが追加されたのはこの問題もたぶん考えてのことでしょう (という理由もあったのかどうかは調べてみないと分かりませんが)。