転送符号化と内容符号化

転送符号化と内容符号化

[28] 実体を (媒体型文字符号化とは別に) 符号化する仕組みとして、 HTTP には内容符号化転送符号化MIME には内容転送符号化があります。

[29] 内容符号化は、本来の意味的には転送される実体の本質的な一部となった符号化を表します。 例えば、 gzip 圧縮されたファイルを転送する場合、内容符号化gzip であるといえます。一方転送符号化は、転送時の都合上の一時的な符号化を表します。 HTTP/1.1 では実体本体全体の長さがわからなくても少しずつ転送を繰り返す chunked 符号化の仕組みがありますが、こちらは転送符号化です。ただし、 歴史的理由により本来転送符号化であるものが内容符号化によって転送されたり、 内容符号化であるものが転送符号化であったかのように扱われたりすることがあります。

HTTPRTSPSIP では内容符号化の識別に 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- がついた名前の方だけが規定に含まれています。

内容符号化の値

[5] 内容符号化を参照。

転送符号化の値

[35] 転送符号化を参照してください。

転送符号化か内容符号化か

[24] 以前は IANAREG には転送符号化として chunked しか登録されておらず、 RFC 2616Transfer-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-Encodinggzip などが追加されたのはこの問題もたぶん考えてのことでしょう (という理由もあったのかどうかは調べてみないと分かりませんが)