[5] Accept:
ヘッダーは、利用者エージェントが受け入れ可能な応答の
MIME型を指定するものです >>416。
[20] 内容折衝は利用者を混乱させるだけなので、使うべきではありません。
Webサーバーは、 Accept:
ヘッダーを無視するべきです。
[435] Accept:
ヘッダーを指定しなければ、
利用者エージェントはどんなMIME型でも受け入れることを表しています >>416。
[420] 欄値は、0個以上の値のリスト (#
) です >>416。
[421] それぞれの値は、媒体範囲、または媒体範囲のあとに
accept-params
を指定したものです >>416。
[422] 媒体範囲は、
MIME型か、MIME型のうち subtype が *
になったものか、
*/*
です。引数も指定できます。 >>416
[423] accept-params
は、
q
引数 (品質値)
および0個以上の引数です。
ここでの引数は、;
、名前、=
、値で構成されます。
ただし ;
の前後には OWS を使えます。
名前は字句で、値は字句または引用文字列です。
=
以下は省略できます。 >>416
[424] 媒体範囲に含まれるMIME型の引数、 accept-params
に含まれる q
引数、その後の引数は、構文としてはほとんど同じですが、
微妙な違いがあります。 q
引数の値は字句でなければなりません。
MIME型の引数の値と q
引数の値は省略できません。
MIME型の引数と、 Accept:
としての引数は、
q
引数の前後どちらかにあるかによって区別します。
[36]
API の versioning に濫用されることがあります。
[427] */*
は、すべてのMIME型を表します >>416。
[428] text/*
のような字句と /*
による指定は、 text/plain
や
text/html
など当該型に属するすべての部分型を表します。 >>416
[429] それ以外は、記述されたMIME型そのものを表します。
[432] q
引数の構文と解釈については、
引数値の項を参照してください。
[433] q
より前にある引数は、MIME型に属するものとして扱われます。
MIME型としての互いの区別に用いられる他は、 Accept:
ヘッダーとしての特別な意味は持ちません。
[434] q
引数の後にある引数は、 Accept:
ヘッダーとしてのオプションを指定するものですが、現在使われている例はありません。
未知の引数をどう扱うかの規定もありません。
[6] Accept:
頭欄を受取った鯖は、
それに従って適当な表現を送ることができるかどうかを調べ、
可能であればそれで応答します。
[436] 起源鯖は、 Accept:
ヘッダーに利用できる表現の
MIME型がない場合は、 406
を送信することもできますし、
内容折衝の対象でない場合のように無視して処理しても構いません >>416。
[17] サーバーによっては、特定の Accept:
が指定されていないと 406
応答を返すことがあります。
例えば JSON と XML を受け付ける Web API がどちらかを選択するために本ヘッダーを使うことがあります。
[10] Accept-Charset:
も参照。
[38] A Guide to the Internet Connection Servers - SG244805.PDF, , http://ps-2.kev009.com/rs6000/redbook-cd/SG244805.PDF#page=58
[39] >>38 この時代の IBM のクライアントは1ヘッダー1MIME型で
Accept:
ヘッダーをずらーっといくつも並べていたらしい。
[40] HTTP Client Profile Proposal (rough draft II), , https://web.archive.org/web/19991125142429/http://www.bsdi.com/HTTP:TNG/MIME-ClientProfile.html
[37] HTTP Client Profile Proposal (rough draft II), , https://web.archive.org/web/19991125142429/http://www.bsdi.com/HTTP:TNG/MIME-ClientProfile.html
関連: WWWWW
The Accept request-header field can be used to
{1945} indicate a list of media rangesspecify certain media types which are acceptable{1945} as a response to the requestfor 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
から
1
の qvalue 尺度を使って示すことが出来ます。
既定値は 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:
は次の優先度を持ちます:
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:
には、次の値が関連付けられます:
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.
注意 : 利用者エージェントはある媒体範囲に品質値の既定集合を提供するかもしれません。 しかし、利用者エージェントが他のレンダリング・エージェントと対話できない閉じたシステムでない限り、 この既定集合は利用者により設定可能とするべきです。
[4]
XML の要素の内容として入れることができる媒体型を
XML Schema 定義文書で記述するための
属性なるものがあります。この値は RFC 2616
の xmlmime:expectedContentTypes
Accept:
頭欄の欄本体と同じです
(ただし使用できる文字の範囲は US-ASCII に限定されています)。
Describing Media Content of Binary Data in XML http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/#expectedContentTypes
[417] HTML の input
要素の accept
属性は Accept:
と似たものとして (曖昧に) 定義されていましたが、
現在は HTML Standard により明確に構文と処理モデルが定義されているため、
類似度は低くなりました。
[418] XHTML2 はリンクの type
属性 (相当)
を (HTML のようなヒントではなく) Accept:
に設定するべき値として使うことを求めていましたが、 XHTML2
全体が支持を集められず、この動作も実装されることはありませんでした。
例:
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 – 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
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
Use the request header Accept: application/zip to download a folder and its contents in the zip format.
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.
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.
要求ヘッダの、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
[31] Be strict on request's Content-Type (annevk著, ) https://github.com/whatwg/fetch/commit/e06e2613f9eef720d0df8640be793efca2af89bc
[32]
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
(Chrome)
[33] Add Accept: */* to CORS-preflight request's headers (perryjiang著, ) https://github.com/whatwg/fetch/commit/412723bae95dcc1541e6aad13b8bf42d8afcfe93
[34] specify default accept header on cors preflight · Issue #922 · whatwg/fetch () https://github.com/whatwg/fetch/issues/922
[35] Add Accept: */* to CORS-preflight requests' headers by perryjiang · Pull Request #941 · whatwg/fetch () https://github.com/whatwg/fetch/pull/941
q
引数以外にAccept:
としての引数は存在しておらず、今後追加されることがあるのかも疑問です。 歴史的にはいくつか存在しており、古い仕様書や古くからある実装が対応していることがあります。