[4] 内容符号化は、 表現に対して適用されている、あるいは適用することができる符号化変形です。 内容符号化は、圧縮などの変形に使うものです。 >>434
[435] 内容符号化の値は、字句で、大文字・小文字不区別です >>434。
[417] 内容符号化を表す値については、 >>3 をご覧ください。
[440] 符号化についての追加の引数は、 Content-Encoding:
とは別のヘッダーによって指定できます >>439。
[438] 内容符号化の値は、 HTTP の Content-Encoding:
ヘッダーや、 Accept-Encoding:
ヘッダー、
encoding
異体属性、
supportedContentEncodings
で用います。
[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
[446] データが常に圧縮される場合など、 MIME型自体に符号化が含まれている場合には、 これは内容符号化としては扱いません。 >>439
[447] 符号化が Content-Type:
に含まれるか
Content-Encoding:
で指定されるかによって動作が変わる
(ダウンロードになったり、自動で展開されてレンダリングされたりする)
利用者エージェントがあることから、起源鯖がその点のみ異なる同じデータの表現を提供することもあり得ます
>>439。
[76] 現実問題として、 内容符号化の用法は何種類か異なるものがあります。
[77]
HTML や CSS など一般のファイル転送に使われる場合
(例えば Content-Encoding: gzip
)。
HTTPサーバーが圧縮して
HTTPクライアントが展開する、
透過的な転送符号化に近い利用法。
通常の Webブラウザーでの
Webサイトの表示のとき、
利用者に気づかれることなく転送を高速化するためによく使われています。
[79]
圧縮されたファイルのダウンロードに使われる場合。
例えば .tar.gz
圧縮されたファイルを配布するサーバーで、
Content-Encoding: gzip
となっていることがあります。
HTTPクライアントは展開しないでそのまま保存することが期待されています。
[81]
暗号化されたデータの転送に用いる場合
(例えば Content-Encoding: aes128gcm
)。
HTTP レベルで符号化や復号ができず、
応用依存の知識がなければただのバイト列としか処理できません。
[70] クライアントもサーバーも、要求や応答で内容符号化を用いる義務はありません。 相手方からどんな指示があろうとも、符号化しない元の状態で送信することができます。 どの内容符号化の符号化も、実装しないことができます。
[69] 汎用の HTTPサーバーの実装の多くは、 gzip
の符号化に対応しています。
それ以外にも対応していることもありますが、あまり普及はしていません。
[32] 起源鯖が応答に適用する内容符号化の決定方法については、
Accept-Encoding:
を参照してください。
[33] 利用者エージェントは要求に通常は内容符号化を適用しませんが、
仕様上要求に内容符号化を適用して Content-Encoding:
を指定することが禁止されているわけではありません。
[64] 通常の要求では内容符号化を使わないため、 サーバーは内容符号化の復号に対応する必要はありません。
[448] 起源サーバーは、要求が受け付けられない内容符号化による表現を含んでいる場合に、
415
で応答して構いません >>439。
サーバーが要求の内容符号化が原因で処理に失敗した時は、
415
応答を返すべきです >>56。
[65] 応答では gzip
内容符号化が使われる場合がよくあります。
Accept-Encoding:
に指定しない限り符号化しない実装が一般的ですので、
クライアントは必ずしも復号に対応しなくても良いかもしれませんが、
それが真にWeb互換であるかどうかは不明瞭です。クライアントは gzip
の復号に対応するべきです。
[66] 応答では deflate
内容符号化が使われることがあります。
復号に対応しないとWeb互換でないといえるほど広く使われているかどうかは疑問ですが、
一般的なクライアントは対応しているので、クライアントは deflate
の復号にも対応するのが良さそうです。
[68] クライアントは br
に対応している場合があります。
現時点では対応しなくてもWeb互換性は損なわれないと考えられています。
[67] クライアントは compress
を含めその他の内容符号化に対応する必要はありません。
[449] Webブラウザーは、 gzip
や deflate
が内容符号化として用いられている場合、これを復号してからレンダリングします。
[49] Webブラウザーは compress
には対応していないようです。
[50] Webブラウザーは未対応の Content-Encoding:
が指定された時、このヘッダーを無視するようです。
[450] ダウンロードの際は、内容符号化を復号しないで保存するのが望ましいと考えられています。
かつてWebブラウザーは内容符号化を復号してから保存していたので、
しばしば tar+gz で配布されているファイルに Content-Encoding:
が指定されており、勝手に展開される上にファイル名に .gz
が含まれたままになるような不都合が起きていました。
[38] クライアントが恒等でない内容符号化が適用された差分を受信した時は、
[42] 串やキャッシュが基底実現値に差分を適用した結果を転送したり、
キャッシュ項目を使って後から転送したりするなら、
その Content-Encoding:
の値は差分の応答
Content-Encoding:
と同じとし、
適用される内容符号化も同じ状態としなければなりません >>35。
[57] サーバーは、要求の内容符号化が原因で 415
応答を返す場合、
応答に Accept-Encoding:
ヘッダーを含めるべきです
>>56。
[58] サーバーは、その他の原因で 415
応答を返す場合、
応答に Accept-Encoding:
ヘッダーを含めてはなりません
>>56。
[3] 次の値が使われていたり、提案されたりしています。
[5] 多分変てこなロボットだと思うんですが、
なぜか Accept-Encoding
に
text/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-Encoding
も gzip
で送ってくるのがほとんど。 (x-gzip
も送ってくる奴も結構いますが。)
[22] SIP は HTTP と内容符号化の名前を共有しています >>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.pm
は Content-Encoding:
の値として base64
や
quoted-printable
を実装しています。
base64
については符号化にも対応しています。
[63] HTTP::Message - search.cpan.org () http://search.cpan.org/~oalders/HTTP-Message-6.13/lib/HTTP/Message.pm
は rot13
を符号化して Content-Encoding:
の値に設定することができますが、
復号には対応していません。
[436] 内容符号化の値は、 IANA に登録するべきです >>434。
[12] IANA登録簿 (>>11) は、転送符号化とは別に設けられています。 しかし、同じ符号化の場合を除き、転送符号化と同じ名前を使ってはならない >>1 とされています。
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
などの形式で配布しているアーカイブのためなのでは無いのですか?
(ten 2004-06-02 11:43:03 +00:00)[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アプリケーションの出力など動的に変化する内容の転送には圧縮を用いるべきではないと考えられます。 動的な内容に適用する時は、それが (境界条件等例外的な場合も含めて) 圧縮しても問題ないことを個別に確認する必要がありますし、 将来の改修によって問題ある状態に変化しないよう相当の注意を払い続ける必要があります。
[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:
ヘッダーの値を変更するか、
表現を復号してから転送するかの操作をするべきです
>>15。
application/octet-stream
に conversions
引数があり、
これは Content-Encoding:
と同じ機能 >>15
とされています。ただし MIME のこの機能は削除されています。[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。 規定がないことには違いありません。
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ビット 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} TheContent-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-coding
が identity
でないなら、応答は使用した非 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.
複数の符号化が実体に適用されている時は、内容符号化はそれが適用された順に列挙しなければなりません。 符号化引数についての追加情報をこの仕様書で定義していない他の実体頭欄で提供しても構いません。
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
[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-streamの 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 は内容符号化値を 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:
IANA が 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-gzip
gzip
(GNU zip)
が生成する符号化書式で、 RFC1952 で説明されている。
この書式はx-compress
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 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].
{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-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: *'.
応答の内容符号化に関する折衝は透過内容折衝とは直交します。
内容符号化を適用しても良い場合についての規則は 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
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