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.

       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 を修正しても構いません。

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 の一部ではありません。)

[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

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つの値を定義します:

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-gzip と x-compress をそれぞれ gzip と compress に等しいものとみなすべきです。

[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 頭を追加することを要求しているのに注意してください。

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.