1 |
#?SuikaWiki/0.9 page-icon="HTTP"
|
2 |
* From specifications
|
3 |
** RFC 2068 & 2616 (HTTP/1.1) 10.4.7 406 Not Acceptable
|
4 |
> The resource identified by the request is only capable of generating
|
5 |
response entities which have content characteristics not acceptable
|
6 |
according to the accept headers sent in the request.
|
7 |
|
8 |
要求で識別される資源は、要求で送られた受入れ頭群に従うと受入れ可能でない内容特徴を持った応答実体を生成する能力しかありません。
|
9 |
|
10 |
> Unless it was a HEAD request, the response SHOULD include an entity
|
11 |
containing a list of available entity characteristics and location(s)
|
12 |
from which the user or user agent can choose the one most
|
13 |
appropriate. The entity format is specified by the media type given
|
14 |
in the Content-Type header field. Depending upon the format and the
|
15 |
capabilities of the user agent, selection of the most appropriate
|
16 |
choice [DEL[may]] [INS[MAY]] be performed automatically. However, this specification
|
17 |
does not define any standard for such automatic selection.
|
18 |
|
19 |
[CODE(HTTP)[[[HEAD]]]] 要求である場合を除き、応答は、
|
20 |
利用可能な実体特徴と位置の一覧を含めて、
|
21 |
利用者又は利用者エージェントが最も適当なものを選ぶことができるようにする'''べきです'''。
|
22 |
実体の書式は [CODE(HTTP)[[[Content-Type]]]] 頭欄に示された[[媒体型]]により規定されます。
|
23 |
その書式と利用者エージェントの能力によっては、
|
24 |
最も適切な選択肢の選択は自動的に行っても'''構いません'''。
|
25 |
しかし、この仕様書はその自動的選択の規格は定義しません。
|
26 |
|
27 |
> Note: HTTP/1.1 servers are allowed to return responses which are
|
28 |
not acceptable according to the accept headers sent in the request.
|
29 |
In some cases, this may even be preferable to sending a 406
|
30 |
response. User agents are encouraged to inspect the headers of an
|
31 |
incoming response to determine if it is acceptable. If the response
|
32 |
could be unacceptable, a user agent SHOULD temporarily stop receipt
|
33 |
of more data and query the user for a decision on further actions.
|
34 |
|
35 |
注意 : HTTP/1.1 サーバーは、要求で送られた受入れ頭群に従うと受け入れ可能でない応答を返すことが認められています。
|
36 |
場合によっては、 [CODE(HTTP)[406]] 応答を送るよりこの方が好ましいかもしれません。
|
37 |
利用者エージェントは、やってくる応答が受入れ可能であるか、その頭を調べることをお勧めします。
|
38 |
応答が受入れ不能であったなら、利用者エージェントはそれ以上のデータの受入れを一時的に停止し、
|
39 |
利用者に以後の動作の決定を求める'''べきです'''。
|
40 |
|
41 |
** RFC 2324 (HTCPCP/1.0) 2.3.1 406 Not Acceptable
|
42 |
>This return code is normally interpreted as "The resource identified
|
43 |
by the request is only capable of generating response entities which
|
44 |
have content characteristics not acceptable according to the accept
|
45 |
headers sent in the request. In HTCPCP, this response code MAY be
|
46 |
returned if the operator of the coffee pot cannot comply with the
|
47 |
Accept-Addition request. Unless the request was a HEAD request, the
|
48 |
response SHOULD include an entity containing a list of available
|
49 |
coffee additions.
|
50 |
> In practice, most automated coffee pots cannot currently provide
|
51 |
additions.
|
52 |
|
53 |
この返し符号は、通常
|
54 |
「その要求により識別される資源は、
|
55 |
その要求中で送られた受入れ (accept)
|
56 |
に従って受入れ可能でない内容性質を持つ応答実体を生成する能力しかない。」と解釈されます。
|
57 |
[[HTCPCP]] では、珈琲ポットの操作者が
|
58 |
[CODE(HTTP)[[[Accept-Addition]]]]
|
59 |
要求を満たすことが出来ない時にこの応答符号を返しても'''構いません'''。
|
60 |
要求が [CODE(HTTP)[[[HEAD]]]]
|
61 |
要求である場合を除いて、応答は受入れ可能な珈琲添加物の一覧を含んだ実体を含める'''べきです'''。
|
62 |
|
63 |
実際には、ほとんどの自動化珈琲ポットは現在の所添加物を提供できません。
|
64 |
|
65 |
** RFC の部分の License
|
66 |
[[RFCのライセンス]]参照。
|
67 |
* メモ |