Accept-Encoding:

Accept-Encoding: ヘッダー (HTTP)

[410] Accept-Encoding: ヘッダーは、 利用者エージェントが受け入れ可能な内容符号化に対して示すものです。

仕様書

意味

[411] 要求Accept-Encoding: ヘッダーは、 応答においてどの内容符号化が受け入れ可能かを利用者エージェントが示すものです >>409

[418] Accept-Encoding: なしの要求は、 利用者エージェント内容符号化について特に好みが無いことを表します >>409

[10] 応答Accept-Encoding: ヘッダーは、 対応する要求において資源が受け入れる意思があった内容符号化を示すものです >>6

[11] 同じサーバーの他の資源が同じ内容符号化を受け入れるとは限りませんし、 同じ資源でも条件や時間の変化で受け入れ可能な内容符号化が変わるかもしれません >>6

構文

[413] 欄値は、0個以上の値のリスト (#) です >>409

  1. ?
    1. 符号化と重み
    2. *
      1. OWS
      2. ,
      3. OWS
      4. 符号化と重み

[414] リストのそれぞれの値は、符号化の名前か、その後に q 引数を指定したものです >>409

[415] 符号化の名前は、内容符号化の名前か、 identity か、 * のいずれかです >>409

  1. |
    1. 字句
    2. *
  2. ?
    1. OWS
    2. ;
    3. OWS
    4. |
      1. q
      2. Q
    5. =
    6. 品質値

[424] 要求Accept-Encoding: ヘッダーがいずれも空なら、 どの内容符号化も望まないことを示しています >>409

[425] identity のみ指定した場合と同じになります。
[427] ほとんどの HTTP/1.0 応用は、 内容符号化q に対応していません >>409

[12] 応答Accept-Encoding: ヘッダーidentity のみが指定されている場合、 どの内容符号化を受け入れられないことを示します >>6

文脈

[412] 複数のヘッダーを指定することもできます。

[7] 要求でも応答でも使うことができます >>6

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

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

内容符号化

[432] 内容符号化の名前としては、 gzipdeflate などを指定できます。大文字・小文字は区別しません。 詳しくは内容符号化の項を参照してください。

*

[416] Accept-Encoding: ヘッダーにおける * は、他に明記されていないすべての利用可能な内容符号化を表します >>409

[417] 内容符号化、とされていますが、 identity も含まれるようです (>>421)。

引数

[433] Accept-Encoding: ヘッダーでは、 q 引数 (だけ) を使えます。 詳しくは品質値を参照してください。

処理

[419] サーバーは、応答を送信するにあたり、 ある表現で適用されている内容符号化が受け入れられるかどうか、 次のようにして決定します >>409

  1. [420] Accept-Encoding: ヘッダーがなければ、 どの内容符号化も受け入れられると考えます。
  2. [421] 当該表現内容符号化無しなら、 identity;q=0 が指定されている場合や identity の指定なしで *;q=0 が指定されている場合を除き、受け入れられます。
  3. [422] 当該表現内容符号化Accept-Encoding: に指定されているもののいずれかであるなら、 q=0 が指定されている場合を除き、受け入れられます。

[423] 複数の内容符号化が受け入れられる場合は、 q が最高の値のものを優先します >>409

[428] 同じ内容符号化が複数回指定されている時、どう解釈するべきかは定義されていません。 q が 0 なら受け入れず、それ以外なら値が大きい方とみなすべきでしょうか。
[429] 同じ値の q内容符号化が複数ある時、 どれを選択するべきかは明記されていません。

[426] 起源鯖は、受け入れられる内容符号化がなければ、 内容符号化なしの応答を送るべきです >>409

[430] 内容折衝の他の観点とは違って、 406 を送るとはされていません。しかし、 406 を返すことや、 Accept-Encoding: を無視して受け入れられない内容符号化で送ることも、 完全には禁止されていません。
[431] .tar.gz ファイルを送る場合など、 Accept-Encoding: を無視してそのまま用意されている内容符号化を使って送るべき場合も少なくなさそうです。

歴史

[1] 古い時代の HTTP では (他の欄同様に) ,; を逆に使ったりすることもありました。

[2] というかそうしていました。

[408] RFC 1945 (HTTP/1.0) D.2.3; RFC 2068・2616 (HTTP/1.1) 14.3 Accept-Encoding

The Accept-Encoding request-header field is similar to Accept, but restricts the {1945,2068} content-coding values {2068} (section 14.12) which {2616} content-codings (section 3.5) that are acceptable in the response.

Accept-Encoding 応答頭欄は、 Accept と同様のものですが、応答で受入れ可能な content-coding を制限します。

{2068,2616}

{2068} An example of its use is {2616} Examples of its use are:

  • Accept-Encoding: compress, gzip
  • {2616} Accept-Encoding:
  • {2616} Accept-Encoding: *
  • {2616} Accept-Encoding: compress;q=0.5, gzip;q=1.0
  • {2616} Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

{2616} A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:

  1. 1. If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in section 3.9, a qvalue of 0 means "not acceptable.")
  2. 2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
  3. 3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
  4. 4. The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.

サーバーは、 Accept-Encoding 欄に従い、次の規則を使って content-coding が受け入れ可能かを検査します:

  1. Content-coding が Accept-Encoding 欄に列挙された content-coding なら、その qvalue0 でない限りは受入れ可能です。 (3.9 節で定義したように、 qvalue 0 は「受入れ不能」を意味します。)
  2. Accept-Encoding 欄中の特殊な * 記号は、 頭欄中に陽に列挙されていない利用可能な content-coding に一致します。
  3. 複数の content-coding が受入れ可能なら、最高の非零 qvalue の受入れ可能 content-coding を優先します。
  4. identity content-coding は、 Accept-Encoding 欄が identity;q=0 を含むか、 *;q=0 を含んで identity content-coding を陽に含んでいないために特に断られていない限り、 常に受入れ可能です。 Accept-Encoding 欄値が空の場合、 identity 符号化だけが受入れ可能です。

If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.

Accept-Encoding 欄が要求に示されている場合、 そしてサーバーが Accept-Encoding 頭に従って受入れ可能な応答を送れない場合は、 サーバーは 406 (受入れ不能) 状態符号で誤り応答を送るべきです

If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. {2616} In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client. {2068} If an Accept-Encoding header is present, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.

Accept-Encoding 欄が要求中に示されていない場合、 サーバーはクライアントがどの内容符号かも受け入れると仮定しても構いません{2616} この場合、 identity が利用可能な content-coding の1つであれば、クライアントにはこれ以外の content-coding に意味があるという追加の情報がない限り、サーバーは identity content-coding を使用するべきです {2068} Accept-Encoding 頭が示されている場合、そしてサーバーが Accept-Encoding 頭に従って受入れ可能な応答を送れない場合は、サーバーは 406 (受入れ不能) 状態符号で誤り応答を送るべきです

{2068} An empty Accept-Encoding value indicates none are acceptable.

空の Accept-Encoding 値は、どれも受け入れ可能でないことを示します。

{2616} Note: If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display messages sent with other content-codings. The server might also make this decision based on information about the particular user-agent or client.

Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will not work and are not permitted with x-gzip or x-compress.

注意 : 要求が Accept-Encoding 欄を含んでいない場合、 そして identity content-coding が利用可能で無い場合、 HTTP/1.0 クライアントが広く理解可能な content-coding (すなわち gzip 及び compress) が優先されます。幾つかの古いクライアントは他の content-coding で送られたメッセージを不適切に表示します。サーバーは特定の利用者エージェントまたはクライアントについての情報にも基づいてこの決定を行うかもしれません。

注意 : ほとんどの HTTP/1.1 応用は content-coding に関連付けられた qvalue を認識したり従ったりしません。 これは、 qvalue が x-gzipx-compress では働かず、認められないことを意味します。

[8] 従来は要求での用法のみ規定されていましたが、 RFC 7694応答でも利用できると拡張しています >>6

[9] 従来応答での利用は明示的に禁止されていたわけではありませんが、 応答に含まれる場合の意味や処理方法が規定されていませんでした。 (品質が低い IETF仕様書を理解するには行間を読む必要があります。 意味が規定されていないなら、認められていないと解釈するのが一般的なようです。)

実装

[3] 今の時代の UA でも、知らない content-coding を使ってるとそのまま表示しちゃったりしますよね。。。

[4] Accept-Encoding を受信したらはそれに従うか 406するべきですRFC 2616 にはありますが、実際の多くの Web頁ではそうはならないようです。 例えば、 Accept-Encoding: *; q=0 とだけあれば必ず 406 が返されるべきですが、 実際にそうなるのは Apache内容折衝が用いられている静的な文書などに限られます。 (名無しさん 2007-11-23 05:49:34 +00:00)

関連

[434] 要求Accept-Encoding: ヘッダーで受け入れを示した内容符号化を実際に応答で使う場合、 応答には Content-Encoding: ヘッダーを設定することになっています。

[435] 内容符号化転送符号化は似ていますが、別のものです。 Accept-Encoding: ヘッダー内容符号化を示すものですが、 これに相当する転送符号化を示すものは、 TE: ヘッダーです。

[436] Network.http.accept-encoding - MozillaZine Knowledge Base ( ( 版)) <http://kb.mozillazine.org/Network.http.accept-encoding>

[5] Welcome to Netscape Navigator Version 2.0 ( 版) <http://web.archive.org/web/20030202175634/http://wp.netscape.com/eng/mozilla/2.0/relnotes/windows-2.0.html>

Options | General Preferences | Language "Accept Language" enables the user to select a prioritized list of language/region codes that reflect what language a user wishes to display a document in, if that document is available in different language translations. The "accept language" information is contained in the HTTP Header's HTTP_ACCEPT_LANGUAGE. A server that provides different language versions of the same content could thus accommodate a user's preferred language.

[13] Specify identity encoding for range requests (jakearchibald著, ) <https://github.com/whatwg/fetch/commit/2f3d04d3713f6cd0f89d491217175b55911927be>

[14] Some servers seem to expect 'Accept-Encoding : identity' to serve Range requests · Issue #747 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/747>

[15] jakearchibald/accept-encoding-range-test () <https://github.com/jakearchibald/accept-encoding-range-test>

[16] Specify identity encoding for range requests. Fixes #747. by jakearchibald · Pull Request #751 · whatwg/fetch () <https://github.com/whatwg/fetch/pull/751>

[17] Additional reasoning for sending Accept-Encoding: identity (jakearchibald著, ) <https://github.com/whatwg/fetch/commit/f342c749b82ad63563fbb2f1b4e84620efe1d63b>

[18] Additional reasoning for sending Accept-Encoding: identity by jakearchibald · Pull Request #764 · whatwg/fetch () <https://github.com/whatwg/fetch/pull/764>