content coding

内容符号化 (HTTP)

[4] 内容符号化 (content coding) は、 表現に対して適用されている、あるいは適用することができる符号化変形 (encoding transformation) です。 内容符号化は、圧縮などの変形に使うものです。 >>434

仕様書

構文

[435] 内容符号化の値は、字句で、大文字・小文字不区別です >>434

[417] 内容符号化を表す値については、 >>3 をご覧ください。

[437] 転送符号化とは違って、引数は指定できません。

[440] 符号化についての追加の引数は、 Content-Encoding: とは別のヘッダーによって指定できます >>439

[441] sdch が独自のHTTPヘッダーを使います。

文脈

[438] 内容符号化の値は、 HTTPContent-Encoding: ヘッダーや、 Accept-Encoding: ヘッダーencoding 異体属性supportedContentEncodings で用います。

[53] 内容符号化は、 HTTP/1.0HTTP/1.1HTTP/2 のいずれでも使うことができます。

[55] 理論上は要求でも >>56 応答でも使うことができます。実際には応答でしか使われません。

意味

[442] メッセージ本体転送符号化復号したものが、 内容符号化が(あれば)適用されているデータです。そこから Content-Encoding: の指定の逆により内容符号化復号することで、 元々のデータが得られます。このデータが、 Content-Type: によって指定されたデータとなります。

[443] 例えば、

Content-Type: text/html; charset=utf-8
Content-Encoding: gzip, deflate
Transfer-Encoding: deflate, chunked
... とヘッダーに指定されている場合、メッセージ本体chunked復号し、 deflate復号し、 再度 deflate復号し、 gzip復号し、 gzip復号すると、 utf-8符号化された HTML文書が得られます。

[444] 転送符号化とは違って内容符号化表現自体の特徴とされており、 他のメタデータも原則として内容符号化された状態に適用されるものです。 普通は内容符号化レンダリングその他の利用の直前に復号されます。 >>439

[445] 転送符号化復号符号化することも認められていますが、 内容符号化はそのような使い方を想定しているものではないようです。

[446] データが常に圧縮される場合など、 MIME型自体に符号化が含まれている場合には、 これは内容符号化としては扱いません。 >>439

[447] 符号化Content-Type: に含まれるか Content-Encoding: で指定されるかによって動作が変わる (ダウンロードになったり、自動で展開されてレンダリングされたりする) 利用者エージェントがあることから、起源鯖がその点のみ異なる同じデータの表現を提供することもあり得ます >>439


[76] 現実問題として、 内容符号化の用法は何種類か異なるものがあります。

[77] HTMLCSS など一般のファイル転送に使われる場合 (例えば Content-Encoding: gzip)。 HTTPサーバー圧縮して HTTPクライアント展開する、 透過的な転送符号化に近い利用法。 通常の Webブラウザーでの Webサイトの表示のとき、 利用者に気づかれることなく転送を高速化するためによく使われています。

[78] 転送符号化gzip などが使えることになっているのは、 こうした用法を想定していたと思われます。ところがほとんど実装されませんでした。 現在一般的に内容符号化が使われています。

[79] 圧縮されたファイルダウンロードに使われる場合。 例えば .tar.gz 圧縮されたファイルを配布するサーバーで、 Content-Encoding: gzip となっていることがあります。 HTTPクライアント展開しないでそのまま保存することが期待されています。

[80] 透過的な用法と区別が難しく、古い Webブラウザーなどは自動的に展開して保存するため、 利用者には不具合と認識されていました。 理論的な健全性のみならず実用上も内容符号化転送符号化を区別するべき理由はここにありました。

[81] 暗号化されたデータの転送に用いる場合 (例えば Content-Encoding: aes128gcm)。 HTTP レベルで符号化復号ができず、 応用依存の知識がなければただのバイト列としか処理できません。

送信者の処理

[70] クライアントサーバーも、要求応答内容符号化を用いる義務はありません。 相手方からどんな指示があろうとも、符号化しない元の状態で送信することができます。 どの内容符号化符号化も、実装しないことができます。

[69] 汎用の HTTPサーバーの実装の多くは、 gzip符号化に対応しています。 それ以外にも対応していることもありますが、あまり普及はしていません。

[32] 起源鯖応答に適用する内容符号化の決定方法については、 Accept-Encoding: を参照してください。

[33] 利用者エージェント要求に通常は内容符号化を適用しませんが、 仕様上要求内容符号化を適用して Content-Encoding: を指定することが禁止されているわけではありません。

ただし対応していないも少なくないでしょうから、事前に何らかの方法で対応する内容符号化を知っていないなら、 使うべきではないでしょう。

[34] 透過内容折衝においては、 Apache の拡張である encoding 異体属性内容符号化が適用された異体であることを明示できます。

[36] 差分符号化された応答生成する時は、 適用する内容符号化の一覧 (Content-Encoding: の値) は差分符号化を使わない時に適用する内容符号化の一覧の接頭辞となっているべきです >>35

[37] この要件に従っていれば、受信者キャッシュしている基底実現値に対してそのまま、または内容符号化復号するだけで、新たに符号化することなく、 差分を適用できます。 >>35

受信者の処理

[64] 通常の要求では内容符号化を使わないため、 サーバー内容符号化復号に対応する必要はありません。

[448] 起源サーバーは、要求が受け付けられない内容符号化による表現を含んでいる場合に、 415応答して構いません >>439サーバー要求内容符号化が原因で処理に失敗した時は、 415 応答を返すべき (ought to) です >>56


[65] 応答では gzip 内容符号化が使われる場合がよくあります。 Accept-Encoding: に指定しない限り符号化しない実装が一般的ですので、 クライアントは必ずしも復号に対応しなくても良いかもしれませんが、 それが真にWeb互換であるかどうかは不明瞭です。クライアントgzip復号に対応するべきです。

[66] 応答では deflate 内容符号化が使われることがあります。 復号に対応しないとWeb互換でないといえるほど広く使われているかどうかは疑問ですが、 一般的なクライアントは対応しているので、クライアントdeflate復号にも対応するのが良さそうです。

[68] クライアントbr に対応している場合があります。 現時点では対応しなくてもWeb互換性は損なわれないと考えられています。

[67] クライアントcompress を含めその他の内容符号化に対応する必要はありません。

[449] Webブラウザーは、 gzipdeflate内容符号化として用いられている場合、これを復号してからレンダリングします。

[49] Webブラウザーcompress には対応していないようです。

[50] Webブラウザーは未対応の Content-Encoding: が指定された時、このヘッダーを無視するようです。

従って正しく表示されません。 MIME Sniffing の対象となる時はダウンロードになるかもしれません。
[51] 常にダウンロードとするか、エラーを表示するのが良さそうではありますが、 もしかすると不適切な設定のページがあって見れなくなってしまうのかもしれません。

[450] ダウンロードの際は、内容符号化復号しないで保存するのが望ましいと考えられています。 かつてWebブラウザー内容符号化復号してから保存していたので、 しばしば tar+gz で配布されているファイルに Content-Encoding: が指定されており、勝手に展開される上にファイル名.gz が含まれたままになるような不都合が起きていました。

[54] 一方で、表示中の文書や画像媒体の保存操作では、 内容符号化復号した方が利用者の意図に即した動作かもしれません。

[38] クライアント恒等でない内容符号化が適用された差分を受信した時は、

[41] 内容符号化が異なる場合で、蓄積された応答側の内容符号化復号しても差分内容符号化と同じ状態にできない場合もあります。 その時は差分は適用できません。

[42] キャッシュ基底実現値差分を適用した結果を転送したり、 キャッシュ項目を使って後から転送したりするなら、 その Content-Encoding: の値は差分応答 Content-Encoding: と同じとし、 適用される内容符号化も同じ状態としなければなりません >>35

[43] これらの制約は、実体タグ実現値 (すなわち、内容符号化の適用後) に関する値であることに由来しています。

[57] サーバーは、要求内容符号化が原因で 415 応答を返す場合、 応答Accept-Encoding: ヘッダーを含めるべき (ought to) です >>56

[58] サーバーは、その他の原因で 415 応答を返す場合、 応答Accept-Encoding: ヘッダーを含めてはなりません >>56

内容符号化の値の一覧

[3] 次の値が使われていたり、提案されたりしています。

7bit
8bit
aesgcm
aesgcm128
aes128gcm
amz-1.0
aws-chunked
base64
binary
br
bzip
x-bzip
bzip2
x-bzip2
compresscompressIETF 原案標準RFC 2616, IANAREG
x-compresscompressIETF 情報提供RFCcompressRFC 1945
deflatedeflateIETF 原案標準RFC 2616, IANAREG
x-deflatedeflatedeflate
exiEXIW3C 作業原案EXI, IANAREG
gzipgzipIETF 原案標準RFC 2616, IANAREG
x-gzipgzipIETF 情報提供RFCgzipRFC 1945
x-hqxBinHex
identity変形なしIETF 原案標準RFC 2616, IANAREG
lzma
none
pack200-gzipJSRJSR#200, IANAREG
peerdist
quoted-printable
rot13
sdch
tar
text/html非標準
text/plain非標準
x_uuencode
x-zipcompresscompress
xz
zstd

[5] 多分変てこなロボットだと思うんですが、 なぜか Accept-Encodingtext/html とか text/plain とか送ってくる奴がいます。数でいうと結構出現頻度が高い。 (同じ奴ばっかだと思うけど。)

[7] Accept-Encoding: 欄に 7bit, 8bit, binary とか書く UA があるらしい。 なんか勘違いしているような気がする。

[8] x-compress, x-gzip は、 HTTP/1.1 が分かる相手には使うべきではありません。 逆に compress, gzip は、 HTTP/1.0 しか分からない相手に使うべきではありません。

[6] 今時は HTTP/1.0 の実装でも x-gzip は知ってるけど gzip は知らないなんてのは無いみたいです。 Accept-Encodinggzip で送ってくるのがほとんど。 (x-gzip 送ってくる奴も結構いますが。)

[22] SIPHTTP内容符号化の名前を共有しています >>21

[23] RFC 3261 には「tar」 という値の例がありますが >>21、定義されていませんし、 IANA にも登録されていません。

[62] HTTP::Message - search.cpan.org () http://search.cpan.org/~oalders/HTTP-Message-6.13/lib/HTTP/Message.pmContent-Encoding: の値として base64quoted-printable を実装しています。 base64 については符号化にも対応しています。

[63] HTTP::Message - search.cpan.org () http://search.cpan.org/~oalders/HTTP-Message-6.13/lib/HTTP/Message.pmrot13 を符号化して Content-Encoding: の値に設定することができますが、 復号には対応していません。

IANA 登録簿

[436] 内容符号化の値は、 IANA に登録するべき (ought to) です >>434

[12] IANA登録簿 (>>11) は、転送符号化とは別に設けられています。 しかし、同じ符号化の場合を除き、転送符号化と同じ名前を使ってはならない >>1 とされています。

誤用

[17] >>16 そのような応答は、 まず Content-Encoding を復号して生に戻した状態で application/x-gzip として解釈するのが正解です。

*.tar.gz を更にもう一度 gzip で圧縮しているのであれば >>16 の通りで何ら問題ありませんが、 *.tar.gz をそのまま送っているのであれば問題です (application/x-tar にでもなっていないと)。

(名無しさん 2004-06-03 00:24:16 +00:00)

セキュリティー

[45] BREACH 攻撃に注意が必要です。機密性の高い内容を扱う場合は攻撃できないように注意して設計するか、 圧縮を用いるべきではありません。

[47] 機密データと攻撃者が制御できるデータを (同じ圧縮辞書で) 一緒に圧縮してはなりません。データの出所が不明なら、 圧縮してはなりません>>46

[48] 実用上は、元から圧縮されているデータの転送や静的ファイルの転送で内容符号化により圧縮することは問題ありませんが、 Webアプリケーションの出力など動的に変化する内容の転送には圧縮を用いるべきではないと考えられます。 動的な内容に適用する時は、それが (境界条件等例外的な場合も含めて) 圧縮しても問題ないことを個別に確認する必要がありますし、 将来の改修によって問題ある状態に変化しないよう相当の注意を払い続ける必要があります。

MIME との関係

[416] Content-Encoding: ヘッダーは名前こそ Content- がつきますが、 MIME では規定されておらず、 HTTP 独自のものです。

[2] 内容符号化は MIME の内容転送符号化や HTTP の転送符号化よりも上 (データ側) の層に当たります。 MIME への関門では媒体型の指定に変換することが良いとされています。 (例: HTTP: Content-Encoding: gzip → MIME: Content-Type: application/x-gzip)

[18] HTTP から MIME に変換するときには、 Content-Type: ヘッダーの値を変更するか、 表現復号してから転送するかの操作をするべき (ought to) です >>15

[19] RFC 1341 時代には application/octet-streamconversions 引数があり、 これは Content-Encoding: と同じ機能 >>15 とされています。ただし MIME のこの機能は削除されています。
[20] MIMECTE内容符号化とは違う機能で、 内容符号化CTE に置き換えることもできません。

透過内容折衝との関係

[26] 透過内容折衝内容符号化内容折衝は直交するものです。 透過内容折衝の結果に内容符号化を適用できます。 >>24

[28] は、透過内容折衝応答内容符号化されていない版を提供できるべきです >>24

[30] Apache の実装では、内容符号化の折衝も透過内容折衝に含めています >>27

encoding も参照。

関連

[419] 合わせて読みたい: 内容符号化と転送符号化HTTP//変形

[418] 内容符号化と転送符号化の項もあわせてご覧ください。

[422] 内容符号化は、 HTTP や派生プロトコルで実体に施されている符号化です。

MIME 的には媒体型に含まれてしまいますが、 媒体型を包含する別の媒体型とでも言うべき、独立したものであることが求められます。 例えば圧縮なら、「PNG で使っている圧縮」のような特定の媒体型に依存したものではなく、「gzip」のように圧縮対象に依存しないものでないといけません。

ホップ間の転送のための必要から行う変形は転送符号化というまた別のものになります。 HTTP の転送符号化は MIME の内容転送符号化にほぼ相当しますが、 これもやはり内容符号化とは別のものです。 (名前が似ているので注意。)

[425] 合成型である multipart/*message/* への適用について HTTP 仕様には明記されていません。

[426] SOAP/JMS では >>425 のケースで意味を未定義と明記しています >>424。 規定がないことには違いありません。

[44] 実現値は、定義上、内容符号化の適用後を指しています。

歴史

[429] RFC 2616 の3.5 Content Codings
   Content coding values indicate an encoding transformation that has
   been or can be applied to an entity. Content codings are primarily
   used to allow a document to be compressed or otherwise usefully
   transformed without losing the identity of its underlying media type
   and without loss of information. Frequently, the entity is stored in
   coded form, transmitted directly, and only decoded by the recipient.
  • content-coding = token
   All content-coding values are case-insensitive. HTTP/1.1 uses
   content-coding values in the Accept-Encoding (section 14.3) and
   Content-Encoding (section 14.11) header fields. Although the value
   describes the content-coding, what is more important is that it
   indicates what decoding mechanism will be required to remove the
   encoding.
   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   content-coding value tokens. Initially, the registry contains the
   following tokens:
   gzip An encoding format produced by the file compression program
        "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
        Lempel-Ziv coding (LZ77) with a 32 bit CRC.

ファイル圧縮プログラム「gzip」(GNU zip) で生成される符号化形式で、 RFC 1952 で説明されているもの。この形式は Lempel-Ziv 符号化 (LZ77) と 32ビット CRC を使っています。

   compress
        The encoding format produced by the common UNIX file compression
        program "compress". This format is an adaptive Lempel-Ziv-Welch
        coding (LZW).

共通 UNIX ファイル圧縮プログラム「compress」で生成される符号化形式。 この形式は Lempel-Ziv-Welch 符号化 (LZW) の一応用です。

        Use of program names for the identification of encoding formats
        is not desirable and is discouraged for future encodings. Their
        use here is representative of historical practice, not good
        design. For compatibility with previous implementations of HTTP,
        applications SHOULD consider "x-gzip" and "x-compress" to be
        equivalent to "gzip" and "compress" respectively.

符号化形式にプログラム名を使うのは望ましいことではなく、 将来の符号化方式には推奨されません。ここで使っているのは 歴史的習慣表現であって、良い設計とはいえません。 HTTP の古い実装との互換性のため、応用は "x-gzip" と "x-compress" をそれぞれ "gzip" および "compress" と同様に解釈するのが 望ましいです。

   deflate
        The "zlib" format defined in RFC 1950 [31] in combination with
        the "deflate" compression mechanism described in RFC 1951 [29].

RFC 1950 で定義された「zlib」形式と RFC 1951 で説明されている 「deflate」 (収縮) 形式を組み合わせたものです。

   identity
        The default (identity) encoding; the use of no transformation
        whatsoever. This content-coding is used only in the Accept-
        Encoding header, and SHOULD NOT be used in the Content-Encoding
        header.

規定 (同等) 符号化方式。無変形に使います。この内容符号化は Accept-Encoding (承認符号化方式) 頭にのみ使われ、 Content-Encoding (内容符号化方式) 頭に使うべきではありません

   New content-coding value tokens SHOULD be registered; to allow
   interoperability between clients and servers, specifications of the
   content coding algorithms needed to implement a new value SHOULD be
   publicly available and adequate for independent implementation, and
   conform to the purpose of content coding defined in this section.
[430] HTTP/1.0 (RFC 1945) から抜粋
       content-coding = "x-gzip" | "x-compress" | token
       Note: For future compatibility, HTTP/1.0 applications should
       consider "gzip" and "compress" to be equivalent to "x-gzip"
       and "x-compress", respectively.

** RFC 1945 (HTTP/1.0) 10.3; RFC 2068 14.12・2616 14.11 (HTTP/1.1) Content-Encoding
> The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms {2068} {1945} must {2068} MUST {2616} must be applied in order to obtain the media-type
referenced by the Content-Type header field. {1945} The Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type.

Content-Encoding 実体頭欄は、媒体型の修飾子として使います。 示されている時、その値は何の追加の内容符号化が entity-body に適用されており、ゆえに Content-Type 頭欄で参照している媒体型を得るためには何の復号機構を適用しなければならないかを示します。 Content-Encoding は主として元々の媒体型の識別を失うことなく文書を圧縮することを可能とするのに使います。

  • Content-Encoding = "Content-Encoding" ":" {2068} 1#content-coding

Content codings are defined in {1945} Section {2068} section 3.5. An example of its use is

  • Content-Encoding: {1945} x-gzip

The {1945,2068} Content-Encoding {2616} content-coding is a characteristic of the {1945} resource {2068} entity identified by the Request-URI. Typically, the {1945} resource {2068} entity-body is stored with this encoding and is only decoded before rendering or analogous usage. {2616} However, a non-transparent proxy MAY modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control directive is present in the message.

content-coding は、 Request-URI] で識別される実体の特徴です。典型的には、 entity-bnody はこの符号化で蓄積され、レンダリングや同様の使用の前にだけ復号されます。 しかし、非透過串は、メッセージに no-transform cache-control 指令が示されていない限り、新しい符号化が受信者に受入れ可能であると分かっているなら、 content-coding を修正しても構いません

{2616} If the content-coding of an entity is not "identity", then the response MUST include a Content-Encoding entity-header (section 14.11) that lists the non-identity content-coding(s) used.

実体の content-codingidentity でないなら、応答は使用した非 identity content-coding を列挙した Content-Encoding 実体頭欄を含めなければなりません

If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).

要求メッセージ中の実体の content-coding が起源サーバーに受け入れ可能でないときには、サーバーは状態符号 415 (未対応媒体型) で反応するべきです

{2068,2616} If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.

Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.

複数の符号化が実体に適用されている時は、内容符号化はそれが適用された順に列挙しなければなりません。 符号化引数についての追加情報をこの仕様書で定義していない他の実体頭欄で提供しても構いません

[431] RFC 1945 (HTTP/1.0) C.3; RFC 2068 (HTTP/1.1) 19.4.3; RFC 2616 (HTTP/1.1) 19.4.4 Introduction of Content-Encoding

RFC 1521 MIME RFC 2045 does not include any concept equivalent to HTTP/1.0 HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols must MUST either change the value of the Content-Type header field or decode the Entity-Body entity-body before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform an equivalent function as {2616} a function equivalent to Content-Encoding. However, this parameter is not part of RFC 1521 MIME RFC 2045.)

[13] RFC 2045 は HTTP/1.1 の Content-Encoding 頭欄に相当する概念を持っていません。 この行為は媒体型を編集するものなので、 HTTP から MIME に従ったプロトコルへの串と関門は Content-Type 頭欄の値を変えるか、実体本体をメッセージ転送の前に復号するかしなければなりません。 (Internet メイルの実験的 Content-Type 応用には媒体型パラメーター ";conversions=<content-coding>" を Content-Encoding に相当する機能に使っているものもあります。 しかし、このパラメーターは RFC 2045 の一部ではありません。)

[14] 訳注: application/octet-streamconversions パラメーターのことかな?

注意: 注記のない修正点は RFC 1945 → RFC 2068 もの。

[432] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 3.5 Content Codings

[421]

Content coding values are used to indicate an encoding transformation that has been or can be applied to an resource entity. Content codings are primarily used to allow a document to be compressed or encrypted otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Typically Frequently, the resource entity is stored in this encoding coded form, transmitted directly, and only decoded before rendering or analogous usage by the recipient.

内容符号化値は、実体に適用されている、またはすることのできる符号化変形を示します。 内容符号化は、主として、もとの媒体型の識別を失うことなく、そして情報を失うことなく、文書を圧縮したり暗号化したりその他有用に変形したりするために使います。 多くの場面では、実体は符号化形で蓄積され、直接転送され、レンダリングや同様の使用の前に受信者によってのみ復号されます。

  • content-coding = "x-gzip" | "x-compress" | token

Note: For future compatibility, HTTP/1.0 applications should consider "gzip" and "compress" to be equivalent to "x-gzip" and "x-compress", respectively.

注意 : 将来との互換性のため、 HTTP/1.0 応用は gzip および compress をそれぞれ x-gzip および x-compress と同等とみなすべきです。

All content-coding values are case-insensitive. HTTP/1.0 HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding ({1945} Section 10.3 section {2068} 14.12 {2616} 14.11) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding. Note that a single program may be capable of decoding multiple content-coding formats. Two values are defined by this specification:

すべての content-coding 値は大文字・小文字を区別しません。 HTTP は内容符号化値を Accept-Encoding 頭欄と Content-Encoding 頭欄で使います。 この値は content-coding を記述しますが、 より重要なことは、この値が符号化を取り除くためにどの復号機構が必要であるかを示しているのだということです。単一のプログラムに複数の content-coding 書式を復号する能力があるかもしれないことに注意してください。この仕様書では2つの値を定義します:

The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:

IANAcontent-coding 値字句の登録簿として機能します。 はじめに、登録簿は次の字句を含みます :

x-gzip
An encoding format produced by the file compression program "gzip" (GNU zip) developed by Jean-loup Gailly as described in RFC 1952 [25] . This format is typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
x-compress

The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch coding (LZW).

x-gzip
Jean‐loup Gailly が開発したファイル圧縮プログラム gzip (GNU zip) が生成する符号化書式で、 RFC1952 で説明されている。 この書式は典型的には Lempel‐Ziv 符号化 (LZ77) に32ビット CRC を加えたものである。
x-compress
共通 UNIX ファイル圧縮プログラム compress が生成する符号化書式。この書式は Lempel‐Ziv‐Welch 符号化 (LZW) を使っている。

{1945,2068} Note: Use of program names for the identification of encoding formats is not desirable and {1945,2068} should be is discouraged for future encodings. Their use here is representative of historical practice, not good design. {2068,2616} For compatibility with previous implementations of HTTP, applications should SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

符号化書式の識別にプログラム名を使うことは望ましくなく、 将来の符号化では非推奨とするべきです。 ここでそうしているのは歴史的なものであって、良い設計ではありません。HTTP の以前の実装との互換性のために、応用x-gzipx-compress をそれぞれ gzipcompress に等しいものとみなすべきです

{2068,2616}

deflate
The "zlib" format defined in RFC 1950[31] in combination with the "deflate" compression mechanism described in RFC 1951[29].

deflate
RFC1950 で定義されている zlib 書式と RFC1951 で説明されている deflate 圧縮機構の組合せ。

{2616}

identity
The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header.

identity
既定 (ママ) 符号化 — 特に何も変形していない。 この content-codingAccept-Encoding 頭でのみ使用し、 Content-Encoding 頭では使用するべきではない

New content-coding value tokens should SHOULD be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new value should SHOULD be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section.

新しい content-coding 値字句は登録するべきですクライアントサーバーの間の相互運用性のために、 新しい値を実装するのに必要な内容符号化算法の仕様書が公開で利用可能であり、独立した実装に適当であり、この節で定義した内容符号化の目的に適合するものであるべきです

注 : 注記なき修正点は RFC 1945 → RFC 2068 における変更。

[433] RFC 2295 (HTTP 透過内容折衝) 10.8 Negotiation on content encoding

[420]

Negotiation on the content encoding of a response is orthogonal to transparent content negotiation. The rules for when a content encoding may be applied are the same as in HTTP/1.1: servers MAY content-encode responses that are the result of transparent content negotiation whenever an Accept-Encoding header in the request allows it. When negotiating on the content encoding of a cacheable response, servers MUST add the accept-encoding header name to the Vary header of the response, or add `Vary: *'.

応答の内容符号化に関する折衝は透過内容折衝とは直交します。 内容符号化を適用しても良い場合についての規則は HTTP/1.1 にあるのと同じで、サーバーは要求の Accept-Encoding 頭が認めているときはいつでも透過内容折衝の結果の応答を内容符号化しても構いませんキャッシュ可能応答の内容符号化の折衝の時には、 サーバーは accept-encoding 頭名を応答の Vary 頭に追加するか、 Vary: * を追加するかしなければなりません

Servers SHOULD always be able to provide unencoded versions of every transparently negotiated response. This means in particular that every variant in the variant list SHOULD at least be available in an unencoded form.

サーバーは、各透過折衝可能応答の符号化されていない版を提供することが常に可能であるべきです。 これは、特に変種目録にある各変種は少なくても符号化されていない形式で利用可能であるべきであることを意味します。

Like HTTP/1.1, this specification allows proxies to encode or decode relayed or cached responses on the fly, unless explicitly forbidden by a Cache-Control directive. The encoded or decoded response still contains the same variant as far as transparent content negotiation is concerned. Note that HTTP/1.1 requires proxies to add a Warning header if the encoding of a response is changed.

HTTP/1.1 同様に、この仕様書は、 Cache-Control 指令が陽に禁じていない限り、中継あるいはキャッシュする応答を串が自動で符号化したり復号したりすることを認めます。 符号化あるいは復号した応答は、透過内容折衝に関する限りは依然として同じ変種を含んでいます。 HTTP/1.1 は串が応答の符号化を変更した時には Warning 頭を追加することを要求しているのに注意してください。

[452] RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES) ( ( 版)) https://tools.ietf.org/html/rfc4236#section-3.2.7

[451] Remove the ability to control content codings. Fixes https://github.com/... · 43f8a7b · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/43f8a7b90f07325a58cc31c33129522443c8b843

メモ

[453] Web サイトの読み込みエラー | Firefox ヘルプ ( ( 版)) https://support.mozilla.org/ja/kb/websites-dont-load-troubleshoot-and-fix-errors#w_kiagianeoeadaeaeiaau

[52] HTTP compression - Wikipedia, the free encyclopedia ( 版) https://en.wikipedia.org/wiki/HTTP_compression

[59] Issue 452335 - chromium - Support Brotli as a content-encoding method on HTTPS connections - Monorail ( 版) https://bugs.chromium.org/p/chromium/issues/detail?id=452335#c12

Also, I'd like to restrict any potential Accept-Encoding schemes to https only to reduce headaches associated with intermediaries. SDCH is littered with workaround hacks to deal with them, and it would be great to remove the need for those on new encoding schemes.

[60] draft-ietf-httpbis-encryption-encoding-01 - Encrypted Content-Encoding for HTTP ( ()) https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-01

[61] draft-reschke-http-oob-encoding-06 - 'Out-Of-Band' Content Coding for HTTP ( ()) https://tools.ietf.org/html/draft-reschke-http-oob-encoding-06

[71] Content codings contract · Issue #58 · httpwg/http-core () https://github.com/httpwg/http-core/issues/58

[72] Handle failure while handling content codings (annevk著, ) https://github.com/whatwg/fetch/commit/939d5851d6fa592de2de1d0d0e53e76c133a4d9b

[73] Define how to handle bad content encoding · Issue #657 · whatwg/fetch () https://github.com/whatwg/fetch/issues/657

[74] Handle failure while handling content codings by annevk · Pull Request #710 · whatwg/fetch () https://github.com/whatwg/fetch/pull/710

[75] Remove Gecko-only quirk by annevk · Pull Request #816 · whatwg/fetch () https://github.com/whatwg/fetch/pull/816

[82] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--compressed