Accept:

Accept: ヘッダー (HTTP)

[5] Accept: ヘッダーは、利用者エージェントが受け入れ可能な応答MIME型を指定するものです >>416

代替

[20] 内容折衝利用者を混乱させるだけなので、使うべきではありません。 Webサーバーは、 Accept: ヘッダーを無視するべきです。

仕様書

意味

[435] Accept: ヘッダーを指定しなければ、 利用者エージェントはどんなMIME型でも受け入れることを表しています >>416

構文

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

[421] それぞれの値は、媒体範囲、または媒体範囲のあとに accept-params を指定したものです >>416

  1. ?
    1. 媒体範囲引数
    2. *
      1. OWS
      2. ,
      3. OWS
      4. 媒体範囲引数

[422] 媒体範囲 (media range) は、 MIME型か、MIME型のうち subtype* になったものか、 */* です。引数も指定できます。 >>416

[423] accept-params は、 q 引数 (品質値) および0個以上の引数です。 ここでの引数は、;、名前、=、値で構成されます。 ただし ; の前後には OWS を使えます。 名前は字句で、値は字句または引用文字列です。 = 以下は省略できます。 >>416

  1. |
    1. */*
    2. =
      1. 字句
      2. /
      3. |
        1. *
        2. 字句
  2. *
    1. OWS
    2. ;
    3. OWS
    4. 字句
    5. ?
      1. =
      2. |
        1. 字句
        2. 引用文字列

[424] 媒体範囲に含まれるMIME型引数accept-params に含まれる q 引数、その後の引数は、構文としてはほとんど同じですが、 微妙な違いがあります。 q 引数の値は字句でなければなりません。 MIME型引数の値と q 引数の値は省略できません。 MIME型引数と、 Accept: としての引数は、 q 引数の前後どちらかにあるかによって区別します。

[425] ただし、 q 引数以外に Accept: としての引数は存在しておらず、今後追加されることがあるのかも疑問です。 歴史的にはいくつか存在しており、古い仕様書や古くからある実装が対応していることがあります。
[11] accept-paramsAccept-Additions: ヘッダーでも使われています。

文脈

[16] このヘッダー要求で指定できます。

[419] このヘッダーは、複数指定できます。

[15] このヘッダーは必須ではありません。

媒体範囲

[426] 媒体範囲は、 MIME型の範囲を表しています。

[427] */* は、すべてのMIME型を表します >>416

[428] text/* のような字句/* による指定は、 text/plaintext/html など当該型に属するすべての部分型を表します。 >>416

[429] それ以外は、記述されたMIME型そのものを表します。

[431] */plain のような指定はできません。

[430] いずれにせよ、引数も指定できます >>416

[438] 媒体範囲は、より詳細な記述が優先度が高い >>416 とされています。

[439] 例えば、

Accept: text/*, text/plain, text/plain;format=flowed, */*
... は、
  1. text/plain;format=flowed
  2. text/plain
  3. text/*
  4. */*
... という優先順を表しています >>416

引数

[432] q 引数の構文と解釈については、 引数値の項を参照してください。

[433] q より前にある引数は、MIME型に属するものとして扱われます。 MIME型としての互いの区別に用いられる他は、 Accept: ヘッダーとしての特別な意味は持ちません。

[434] q 引数の後にある引数は、 Accept: ヘッダーとしてのオプションを指定するものですが、現在使われている例はありません。 未知の引数をどう扱うかの規定もありません。

処理

[6] Accept: 頭欄を受取った鯖は、 それに従って適当な表現を送ることができるかどうかを調べ、 可能であればそれで応答します。

[436] 起源鯖は、 Accept: ヘッダーに利用できる表現MIME型がない場合は、 406 を送信することもできますし、 内容折衝の対象でない場合のように無視して処理しても構いません >>416

[437] どちらの挙動が有用かは状況にも依存するので、判断が難しいところです。

[17] サーバーによっては、特定の Accept: が指定されていないと 406 応答を返すことがあります。 例えば JSONXML を受け付ける Web API がどちらかを選択するために本ヘッダーを使うことがあります。

[18] 汎用的なクライアントは事前にどのような値を送信するべきか決定できません。 個別のサーバー資源に応じて適切な値を設定する必要があります。 このようなサーバーの挙動は (たまに見られるものの) 一般的とは言えず、 クライアントに不便を強いるだけですから、サーバーの実装者はそのような設計にせずに、 いずれかの適切な形式を自動的に選択するべきと思われます。

[10] Accept-Charset: も参照。

歴史

[415] RFC 1945 (HTTP/1.0) D.2.1; RFC 2068・2616 (HTTP/1.1) 14.1 Accept

The Accept request-header field can be used to {1945} indicate a list of media ranges specify certain media types which are acceptable {1945} as a response to the request for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.

Accept 要求頭欄は、 応答で受入れ可能な媒体型を指定するのに使うことが出来ます。 Accept 頭は、要求が行内画像の要求の場合のように望まれる型の小さな集合に限定することを示すのに使うことが出来ます。

{2068,2616}

The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. {1945} The set of ranges given by the client should represent what types are acceptable given the context of the request. {2068,2616} The media-range MAY include media type parameters that are applicable to that range.

星印 * 文字は、媒体型の範囲を集団化するのに使います。 */* は全ての媒体型を示し、 type/* はその型の全ての部分型を示します。 media-range は、その範囲に適用可能な媒体型引数を含んでいても構いません

{2068,2616} Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1.

media-range の後には、 相対的品質因子を示す q 引数で始まる、 1つ以上の accept-params を続けても構いません。 最初の q 引数は、 (あれば) media-range 引数(群)を accept-params から分離します。 品質因子は利用者または利用者エージェントがその media-range を優先させる想定的な度合いを、 0 から 1qvalue 尺度を使って示すことが出来ます。 既定値は q=1 です。

Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types should be discouraged from registering any parameter named "q".

注意 : q 引数名を、媒体型引数を Accept 拡張引数から分離するのに使うのは歴史的慣習です。 このために q という名前の媒体型引数を媒体範囲に使うことが出来ませんが、 そのような事象は起こりそうもないであろうと信じられています。 IANA 媒体型登録簿には q 引数はありませんし、 Accept 中での任意の媒体型の引数の使用も稀なことです。 将来の媒体型が q という名前の引数を登録することは非推奨されるべきです。

The example

  • Accept: audio/*; q=0.2, audio/basic

SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."

という例は、「私は audio/basic を最優先しますが、 80% 落とした品質でそれが最善であれば任意の音声型を送ってください。」 と解釈されるべきです

If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

Accept 頭欄が示されていなかった場合、 クライアントは全ての媒体型を受け入れると仮定します。 Accept 頭欄が示されている場合、 そしてサーバーが結合 Accept 欄値に従って受け入れ可能な応答を遅れない場合、 サーバーは 406 (受入れ不能) 応答を送るべきです

A more elaborate example is

  • Accept: text/plain; q=0.5, text/html,
                      text/x-dvi; q=0.8, text/x-c

Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."

言葉で言えば、これは「text/html 及び text/x-c が最優先媒体型ですが、これらが存在しない場合には、 text/x-dvi 実体を送り、それも存在しない場合には、 text/plain 実体を送ってください。」と解釈されます。

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,

媒体範囲は特定媒体範囲または特定媒体型で上書き可能です。 ある型に複数の媒体範囲が適用できるなら、 最も特定した参照が優先されます。例えば、

  • Accept: text/*, text/html, text/html;level=1, */*

have the following precedence:

は次の優先度を持ちます:

  1. 1) text/html;level=1
  2. 2) text/html
  3. 3) text/*
  4. 4) */*

The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,

ある型に関連付けられた媒体型品質因子は、 その型に一致する最高の優先度の媒体範囲を探すことで決定します。 例えば、

  • Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

には、次の値が関連付けられます:

  • text/html;level=1 = 1
  • text/html = 0.7
  • text/plain = 0.3
  • image/jpeg = 0.5
  • text/html;level=2 = 0.4
  • text/html;level=3 = 0.7

Note: A user agent may be provided with a default set of quality values for certain media ranges. However, unless the user agent is a closed system which cannot interact with other rendering agents, this default set should be configurable by the user.

注意 : 利用者エージェントはある媒体範囲に品質値の既定集合を提供するかもしれません。 しかし、利用者エージェントが他のレンダリング・エージェントと対話できない閉じたシステムでない限り、 この既定集合は利用者により設定可能とするべきです。

実装

[440] Webブラウザーは、文脈によって違う値を設定するようです。

関連

[4] XML要素内容として入れることができる媒体型XML Schema 定義文書で記述するための xmlmime:expectedContentTypes 属性なるものがあります。この値は RFC 2616Accept: 頭欄の欄本体と同じです (ただし使用できる文字の範囲は US-ASCII に限定されています)

Describing Media Content of Binary Data in XML <http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/#expectedContentTypes>

[417] HTMLinput 要素accept 属性Accept: と似たものとして (曖昧に) 定義されていましたが、 現在は HTML Standard により明確に構文と処理モデルが定義されているため、 類似度は低くなりました。

[418] XHTML2リンクtype 属性 (相当) を (HTML のようなヒントではなく) Accept: に設定するべき値として使うことを求めていましたが、 XHTML2 全体が支持を集められず、この動作も実装されることはありませんでした。

例:

(q の既定値は 1 なので、この二例は等価。)

Accept: 要求頭欄は、ひとつの HTTP 要求メッセージ中に任意個 (零個以上) 入れることができます。複数個存在する場合には、一般の HTTP の頭欄の取扱いの規則により、すべてを読点分離でひとまとめにしたものと等価として扱います。

例:

Accept: text/plain
Accept: text/html

は、

Accept: text/plain,text/html

と等価です。

メモ

[7] >>2 Apache なんかは q 引数が同順位だと前ほど優先するようなので、 WinIE 6 がこのような Accept: 欄を送ってくることを利用して、 通常の WWWブラウザ向けの高品質画像を PNG (image/png) で、 WinIE 向けの低品質画像を GIF で送り返すような技が使えます。 (都合がいいことに他の主要 WWWブラウザGIF よりも PNG を優先させてくれます。) (名無しさん)

[8] Accept欄の構文解析を一々するのは面倒なので、適当な正規表現一致で済ませたくなりますが、 できるだけ正確に検査した方が無難です。

特に注意しないといけないのは、q=0の場合があることです。Accept欄にある媒体型があったとしても、それが本当に受け入れられるものかどうかはqをみないとわかりません。 (名無しさん)

[9] Bug 309438 &#8211; Accept: header too long on account of text types (2007-02-26 08:33:13 +09:00 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=309438>

[407] IRC logs: freenode / #whatwg / 20110416 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20110416#l-39>

[408] [whatwg] RWD Heaven: if browsers reported device capabilities in a request header ( ( 版)) <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034642.html>

[409] IRC logs: freenode / #whatwg / 20120206 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120206>

[410] Request Headers in the HTTP protocol ( ( 版)) <http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3>

[411] RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2) ( ( 版)) <http://tools.ietf.org/html/rfc6787#section-6.2.2>

[412] [whatwg] microdata questions ( ( 版)) <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-April/084610.html>

[413] HTTP - WHATWG Wiki ( ( 版)) <http://wiki.whatwg.org/wiki/HTTP#Accept_header>

[414] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) <http://tools.ietf.org/html/rfc7252#section-5.10.4>

[441] OData Version 4.0 Part 1: Protocol Plus Errata 01 ( ( 版)) <http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html#_Toc393958667>

[442] OData Version 4.0 Part 1: Protocol Plus Errata 01 ( ( 版)) <http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html#_Toc370374804>

[443] Request Headers in the HTTP protocol ( ( 版)) <http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3>

[444] HTTP::Negotiate - search.cpan.org ( ( 版)) <http://search.cpan.org/~gaas/HTTP-Negotiate-6.01/lib/HTTP/Negotiate.pm#Accept>

[445] HTTP::Negotiate - search.cpan.org ( ( 版)) <http://search.cpan.org/~gaas/HTTP-Negotiate-6.01/lib/HTTP/Negotiate.pm#Accept>

[446] HTTP::Negotiate - search.cpan.org ( ( 版)) <http://search.cpan.org/~gaas/HTTP-Negotiate-6.01/lib/HTTP/Negotiate.pm#Accept>

[12] Set Accept/Accept-Language in Fetch per #43 · whatwg/fetch@d095fdc ( 版) <https://github.com/whatwg/fetch/commit/d095fdcf284cd36e9ddee526ad6faa6fda4ecc00>

[13] Accept/Accept-Language handling is now done in Fetch · whatwg/xhr@7e8e1d8 ( 版) <https://github.com/whatwg/xhr/commit/7e8e1d887c2b16ba4665c849e7034a45ab826ec3>

[14] Fix #142: always give `Accept` a default value · whatwg/fetch@ceb16ef ( 版) <https://github.com/whatwg/fetch/commit/ceb16efa37f3888323b47a6529124c4fcefa5e33>

[19] Clarify requirements around Accept and Accept-Language · whatwg/fetch@69eda57 ( 版) <https://github.com/whatwg/fetch/commit/69eda57af99fd5762162f24739da1895bd2130f4>

[21] 1249474 – Accept header sent for images prevents w3.org from serving us SVG images in W3C's style sheet ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=1249474>

[22] draft-cooper-webi-wpad-00 - Web Proxy Auto-Discovery Protocol ( ()) <https://tools.ietf.org/html/draft-cooper-webi-wpad-00#section-5.6>

The client then requests the CURL via HTTP. When making the request

it MUST transmit HTTP "Accept" headers indicating what CFILE formats

it is capable of accepting. For example, Netscape Navigator browsers

with versions 2.0 and beyond might include the following line in the

HTTP Request:

Accept: application/x-ns-proxy-autoconfig

[23] Git Trees | REST API Reference for Visual Studio Team Services and Team Foundation Server (Robert Outlaw著, ) <https://www.visualstudio.com/ja-jp/docs/integrate/api/git/trees>

Use the request header Accept: application/zip to download a folder and its contents in the zip format.

[24] Web Annotation Protocol () <https://w3c.github.io/web-annotation/protocol/wd/#h-annotation-retrieval>

Servers may support different JSON-LD profiles. Content negotiation for different JSON-LD profiles is performed by adding a profile parameter to the JSON-LD media type in a space separated, quoted list as part of the Accept header.

[25] CircleCI API v1.1 Reference - CircleCI () <https://circleci.com/docs/api/v1-reference/>

If you specify no accept header, we’ll return human-readable JSON with comments. If you prefer to receive compact JSON with no whitespace or comments, add the "application/json" Accept header.

[26] 生テレを眺めた - rencontRe Lab (minolabo著, ) <http://nyarudiary.blog.fc2.com/blog-entry-126.html>

要求ヘッダの、Acceptヘッダフィールドに、

Accept: application/json;pk=abcdefg1234567890(一例)

Accept:application/json;pk=BCpkADawqM0JuhdAR5ltYcF75lYGhlH-BMDUvcu5ryEdXB90DClTPOjHAWLNL9TfxPUeOHlM1LsBB74Rq8Vm7J_khrxLYtPwfOVtRzHVqHLcAt59eHMYeHT7S6yYPnp_df737dsxTHIJe_W6

を付けてあげれば401(Unauthorized)とならずに、ステータスコードは200(正常)となる。

[27] Fold request type into destination (annevk著, ) <https://github.com/whatwg/fetch/commit/d7052e2b6d24d04caa2cea8ef664923ecdb1e35c>

[28] Release Notes for Safari Technology Preview 46 | WebKit () <https://webkit.org/blog/8042/release-notes-for-safari-technology-preview-46/>

[29] Listing headers safe only for certain values is a bad idea · Issue #313 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/313>

[30] Strengthen requirements on CORS-safelisted request-headers (annevk著, ) <https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b>