supportedContentEncodings
で用います。
Content-Type: text/html; charset=utf-8 Content-Encoding: gzip, deflate Transfer-Encoding: deflate, chunked... と
chunked deflate deflate gzip gzip utf-8
gzip などが使えることになっているのは、
こうした用法を想定していたと思われます。ところがほとんど実装されませんでした。
現在一般的に.tar.gz
gzip の
gzip Accept-Encoding: に指定しない限り符号化しない実装が一般的ですので、
gzip
の
deflate deflate
の
br に対応している場合があります。
現時点では対応しなくても
compress を含めその他の
.gz
が含まれたままになるような不都合が起きていました。
7bit8bitaesgcmaesgcm128aes128gcmamz-1.0aws-chunkedbase64binarybrbzipx-bzipbzip2x-bzip2→ 変形なし nonerot13非標準 非標準 → zstd
Accept-Encoding に
text/html とか text/plain
とか送ってくる奴がいます。数でいうと結構出現頻度が高い。
(同じ奴ばっかだと思うけど。)
x-compress, x-gzip は、
compress, gzip は、
x-gzip は知ってるけど gzip は知らないなんてのは無いみたいです。 Accept-Encoding も gzip で送ってくるのがほとんど。 (x-gzip も送ってくる奴も結構いますが。)
Content-Encoding: の値として base64 や
quoted-printable を実装しています。
base64 については符号化にも対応しています。
rot13 を符号化して Content-Encoding: の値に設定することができますが、
Content-Encoding: gzip かつ Content-Type: application/x-gzip/etc /mime.types application/x-gzip .gz って書いてある、って話だったりします。ちょっと困ったもんです。Content-Encoding: gzip かつ Content-Type: application/x-gzip*.tar.gz などの形式で配布しているアーカイブのためなのでは無いのですか?
(Content-Encoding を復号して生に戻した状態で application/x-gzip として解釈するのが正解です。
*.tar.gz を更にもう一度 gzip
で圧縮しているのであれば *.tar.gz をそのまま送っているのであれば問題です
(application/x-tar にでもなっていないと)。
(
Content- がつきますが、
application/octet-stream conversions Content-Encoding: encoding
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.
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ビット
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-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-codingis 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 は、 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-coding が 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
が起源サーバーに受け入れ可能でないときには、サーバーは状態符号
{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.
複数の符号化が実体に適用されている時は、内容符号化はそれが適用された順に列挙しなければなりません。 符号化引数についての追加情報をこの仕様書で定義していない他の実体頭欄で提供しても構いません。
RFC 2045 does not include any concept equivalent toRFC 1521MIMEHTTP/1.0HTTP/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 protocolsmustMUST either change the value of the Content-Type header field or decode theEntity-Bodyentity-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 performan equivalent function as{2616} a function equivalent to Content-Encoding. However, this parameter is not part ofRFC 2045.)RFC 1521MIME
conversions
パラメーターのことかな?
注意: 注記のない修正点は RFC 1945 → RFC 2068 もの。
Content coding values
are used toindicate an encoding transformation that has been or can be applied to anresourceentity. Content codings are primarily used to allow a document to be compressed orencryptedotherwise usefully transformed without losing the identity of its underlying media type and without loss of information.TypicallyFrequently, theresourceentity is stored inthis encodingcoded form, transmitted directly, and only decodedbefore rendering or analogous usageby 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.0HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding ({1945} Section 10.3section{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 は内容符号化値を 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:
content-coding 値字句の登録簿として機能します。
はじめに、登録簿は次の字句を含みます :
x-gzip- An encoding format produced by the file compression program "gzip" (GNU zip)
developed by Jean-loup Gaillyas described in RFC 1952 [25] . This format istypicallya Lempel-Ziv coding (LZ77) with a 32 bit CRC.x-compressThe encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch coding (LZW).
x-gzipgzip (GNU zip)
が生成する符号化書式で、 x-compresscompress が生成する符号化書式。この書式は Lempel‐Ziv‐Welch
符号化 (
{1945,2068} Note:Use of program names for the identification of encoding formats is not desirable and{1945,2068} should beis discouraged for future encodings. Their use here is representative of historical practice, not good design. {2068,2616} For compatibility with previous implementations of HTTP, applicationsshouldSHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
符号化書式の識別にプログラム名を使うことは望ましくなく、
将来の符号化では非推奨とするべきです。
ここでそうしているのは歴史的なものであって、良い設計ではありません。HTTP の以前の実装との互換性のために、x-gzip と x-compress をそれぞれ gzip と compress に等しいものとみなすべきです。
{2068,2616}
- deflate
- The "zlib" format defined in RFC 1950[31] in combination with the "deflate" compression mechanism described in RFC 1951[29].
deflatezlib
書式と 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.
identitycontent-coding は Accept-Encoding Content-Encoding New content-coding value tokens
shouldSHOULD be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new valueshouldSHOULD 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 における変更。
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: *'.
応答のaccept-encoding 頭名を応答の 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 同様に、この仕様書は、
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.