/
233.txt
239 lines (181 loc) · 14 KB
/
233.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
[305] [DFN[[RUBYB[[[表現]]]@en[representation]]]]とは、 [[HTTP]]
において読み書きその他の処理の対象となるデータのことをいいます。
* 仕様書
[REFS[
- [6] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-3>
-- [306] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-3.1>
- [3] [CITE@en[RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests]] ([TIME[2014-09-11 10:02:44 +09:00]] 版) <https://tools.ietf.org/html/rfc7232#section-2.1>
- [9] [CITE@en[RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests]] ([TIME[2014-09-11 10:02:44 +09:00]] 版) <https://tools.ietf.org/html/rfc7232#section-4.1>
- [16] [CITE@en[RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests]] ([TIME[2014-09-11 09:57:55 +09:00]] 版) <https://tools.ietf.org/html/rfc7233#section-4.1>
- [22] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229#page-7>
- [26] [CITE@en[RFC 3230 - Instance Digests in HTTP]] ([TIME[2014-08-31 18:57:37 +09:00]] 版) <http://tools.ietf.org/html/rfc3230#page-6>
- [18] [CITE@en[RFC 7240 - Prefer Header for HTTP]] ([TIME[2014-07-26 04:24:01 +09:00]] 版) <https://tools.ietf.org/html/rfc7240#section-4.2>
]REFS]
* 定義
[8] [[RFC 7231]] は、次のように説明しています [SRC[>>6]]。
>
[7] [[資源]]は何であっても良いとし、 [[HTTP]] が提供する一様なインターフェイスが独立した他者に対する[[メッセージ]]のやり取りによってだけそれを観察したり作用したりできるような[[窓]]のようなものであると考えると、
やり取りにおいてそれの現在の状態や望む状態を表現する (代わりとなる)
抽象化が必要となります。この抽象化を、[[表現]]と呼びます [SRC[[[REST]]]]。
>
[[HTTP]] においては、「[[表現]]」は、特定の[[資源]]の過去や現在の、あるいは望ましい状態を反映することを意図した情報であって、
[[プロトコル]]を通じて通信することができる形式にあるもので、
[[表現メタデータ]]の集合と表現データの無限かもしれない[[ストリーム]]によって構成されるものです。
>
[[起源鯖]]は、[[対象資源]]の現在の状態を反映することを意図した複数の[[表現]]を提供されていたり、
[[生成]]することができたりします。そのような場合、
特定の[[要求]]に最も適切な、通常は[[内容折衝]]に基づく、
いずれかの[[表現]]を[[起源鯖]]が選択するアルゴリズムが用いられます。
この「選択された表現」は、[[条件付き要求]]の評価や
[CODE(HTTP)@en[[[GET]]]] に対する [CODE(HTTP)[[[200]]]] や [CODE(HTTP)[[[304]]]]
の[[応答]]の [[payload]] の構築でデータやメタデータとして使われます。
;; [405] [[資源]]と[[表現]]は、平易な表現に見えて実は難解な [[HTTP]]
の専門用語の代表格といえます。 [[HTTP]] [[RFC]] の著者達以外に正しく理解している人がどれだけいるのでしょう。
;; [406] 概念の [[overengineering]] な気もしますが...
* 選択された表現
[11] [[表現]]の候補が1つ以上ある場合に、[[内容折衝]]などの条件によって選ばれた[[表現]]のことを特に[DFN[[RUBYB[[[選択された表現]]]@en[selected representation]]]]と呼んでいます。
[12] 「[CODE(HTTP)@en[[[GET]]]] [[メソッド]]だったら返されるであろう[[表現]]」
のような呼ばれ方をしているものと同じと思われます。
[27] ただし「[CODE(HTTP)@en[[[PUT]]]] [[メソッド]]が [CODE(HTTP)@en[[[GET]]]]
[[メソッド]]で返される[[表現]]を置き換える」と言った場合に[[内容表現]]の影響をどう評価しているのかは、
これだけからは明らかではありません。
[28] [[WebDAV]] は「[[accept header]] なしの [CODE(HTTP)@en[[[GET]]]]
で返される」といった言い方を使っています。
[2] 「[[選択された表現]]」は [[RFC 3229]]/[[RFC 3230]] の[[実現値]]とほぼ同じ意味に見えますが、
明言されておらずはっきりしません。
[24] [DFN[[RUBY[実現値]@en[インスタンス]@en[instance]]]]は、
その時点で指定された[[資源]]の選択された[[異体]]に対しての [CODE(HTTP)@en[[[GET]]]]
[[要求]]への[[状態符号]]が [CODE(HTTP)[[[200]]]] の[[応答]]で返されるであろう[[実体]]で、
0個以上の[[内容符号化]]の適用後であって、[[実現値操作]]や[[転送符号化]]の適用前のものをいいます [SRC[>>22, >>26]]。
;; [25] [[RFC 723x]] 世代の用語だと[[実体]]は [[payload]] と読み替える感じでしょうか。
[13] [[選択された表現]]は、[[応答メッセージ]]に含まれるとは限りません。例えば
[CODE(HTTP)@en[[[PUT]]]] では[[選択された表現]]が新たなものに変更されますが、
変更の前の[[表現]]も後の[[表現]]も[[応答メッセージ]]に含まれるとは限りません。
* 対象資源以外の表現
[310] ところで[[要求メッセージ]]の [[payload]] に含まれるデータのことや、
[CODE(HTTP)[[[404]]]] や [CODE(HTTP)[[[303]]]] などの[[応答]]の [[payload]]
に含まれるデータのことも「[[表現]]」と呼ばれているようですが、
これらも定義上の[[表現]]の範囲に入っているのかはよくわかりません。
少なくても [CODE(HTTP)[[[200]]]] で [[payload]] に含まれる“[[対象資源]]の”[[表現]]とは異なるものとして扱われているようですが...
* 現在の表現
[14] [[対象資源]]の[[表現]]は、時を経て変更されることがあります。
ある時点での状態を指す時に[RUBYB[現在の表現]@en[current representation]]という言葉が使われます。
;; [15] [[内容折衝]]のために現在の[[表現]]が複数存在するかもしれません。
* ヘッダー
[307] 次の[[ヘッダー]]は、[DFN[[RUBYB[[[表現メタデータ]]]@en[representation metadata]]]]
([DFN[[RUBYB[表現ヘッダー]@en[representation header (field)]]]]) に分類されています
[SRC[>>306]]。
[FIG(list short)[
- [CODE(HTTP)@en[[[Content-Type:]]]]
- [CODE(HTTP)@en[[[Content-Encoding:]]]]
- [CODE(HTTP)@en[[[Content-Language:]]]]
- [CODE(HTTP)@en[[[Content-Location:]]]]
]FIG]
;; [10] [CODE(HTTP)@en[[[Content-*]]]] がすべて[[表現メタデータ]]ではありません。
[CODE(HTTP)@en[[[Content-Range:]]]] や [CODE(HTTP)@en[[[Content-Length:]]]]
は [[payload header]] に分類されています。
[308] [[メッセージ]]に [[payload body]] が含まれるときは、 [[payload body]]
に含まれる[[表現]]データの解釈方法を表します [SRC[>>306]]。
[309] [CODE(HTTP)@en[[[HEAD]]]] [[要求]]に対する[[応答]]の時は、
[CODE(HTTP)@en[[[GET]]]] だった場合の[[応答]]に含まれる[[表現]]データの解釈方法を表します
[SRC[>>306]]。
[4] [[RFC 7232]] は[[検証子]]のことを[[表現メタデータ]]と呼んでいますが [SRC[>>3, >>9]]、
[[検証子ヘッダー]]と >>307 は[[互いに素]]であり、両者の関係性は不明確です。
[CODE(HTTP)[[[304]]]] の規定においてはこの広い意味の[[表現メタデータ]]が使われています。
[17] [[RFC 7233]] は[[表現ヘッダー]] (representation header field)
という用語を使っており [SRC[>>16]]、意味的には >>4
と同じものを指していそうですが、真の意図は不明です。
* [CODE(HTTP)@en[Prefer: return=representation]]
[19] [CODE(HTTP)@en[[[Prefer:]] [[return]]=[DFN[[[representation]]]]]] は、
成功した[[要求]]に対する[[応答]]は[[資源]]の現在の状態の[[表現]]とするべきことを[[クライアント]]が望んでいることを示します
[SRC[>>18]]。
** 引数
[29] [CODE(HTTP)@en[[[Prefer:]] [[return]]=[[representation]]]]
に指定する[[引数]]として、 [CODE(HTTP)@en[[[include]]]] と [CODE(HTTP)@en[[[omit]]]]
があります。
** 処理
;; [3] [CODE(HTTP)@en[[[Prefer:]]]], [CODE(HTTP)@en[[[return]]]] も参照。
[20] [CODE(HTTP)@en[[[Prefer:]] [[return]]=[[representation]]]] が指定された場合、
[[応答]]の [[payload body]] は当該[[要求]]の処理の適用後の適用対象の[[資源]]の[[表現]]とすることが期待されています。
[21] その際、当該[[表現]]は[[実効要求URL]]の[[表現]]ではなく、他の[[資源]]の[[表現]]である場合もあります。その場合は返された[[表現]]の
[[URL]] を [CODE(HTTP)@en[[[Content-Location:]]]] [[ヘッダー]]で指定できます [SRC[>>18]]。
* 歴史
** HTTP RFC
[FIG(quote)[
[FIGCAPTION[
[1] [[HTTP]] ([[RFC 2068]] 1.3, [[RFC 2616]] 1.3)
]FIGCAPTION]
>
:representation: An entity included with a response that is subject to content
negotiation, as described in section 12. There may exist multiple
representations associated with a particular response status.
:表現: [[内容折衝]]の対象である応答に含まれている[[実体]]。
特定の応答状態に関連付けられた複数の表現が存在するかもしれない。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[5] [CITE@en[RFC 5023 - The Atom Publishing Protocol]] ([TIME[2008-11-20 18:52:14 +09:00]] 版) <http://tools.ietf.org/html/rfc5023#section-3>
]FIGCAPTION]
>
: [DFN[[RUBYB[表現]@en[representation]]]]:
[[RFC 2616]] で定義されている通り[[要求]]や[[応答]]に含まれる[[実体]]。
]FIG]
** 差分符号化
[FIG(quote)[
[FIGCAPTION[
[23] RFC 3229 (差分符号化), RFC 3230 (要約) の用語定義より抜粋
]FIGCAPTION]
> The dictionary definition for "entity" is "something that has
separate and distinct existence and objective or conceptual reality" [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is
similar to that used in MIME [12], based on a false analogy between
MIME and HTTP.
「[[実体]]」の辞書的定義は「分離された異なる存在ならびに物体的または概念的現実性を有するもの」です。
不幸にも、 HTTP/1.1 の「実体」の定義は [[MIME]] で使われているものと同様で、
完全に間違った MIME と HTTP との類似性に基づいています。
> In MIME, electronic mail messages do have distinct and separate
existences. MIME defines "entity" as something that "refers
specifically to the MIME-defined header fields and contents of either
a message or one of the parts in the body of a multipart entity."
MIME では、電子メイル・メッセージは異なる分離された存在を有していました。
MIME は「実体」を「メッセージまたは[[多部分実体]]の本体中の[[部分]]の一つのいずれかの MIME 定義[[頭欄]]および[[内容]]を特に指す」ものとして定義しています。
> In HTTP, however, a response message to a GET does not have a
distinct and separate existence. Rather, it reflects the current
state of a resource (or a variant, subject to a set of constraints).
The HTTP/1.1 specification has no term to describe "the value that
would be returned in response to a GET request at the current time
for the selected variant of the specified resource." This leads to
awkward wordings in the HTTP/1.1 specification in places where this
concept is necessary.
しかし、 HTTP では、 [CODE(HTTP)[[[GET]]]] に対する[[応答メッセージ]]は異なる分離された存在を有していません。
むしろ、応答メッセージは資源の現在の状態 (制約の集合の対象となる、[[変体]])
を記述しています。 HTTP/1.1 仕様書は「指定された資源の選択された変体についての現時点で
[CODE(HTTP)[GET]] 要求に対する応答で返されることになる値」
を記述する用語を提供していません。このために、 HTTP/1.1
仕様書でこの概念が必要なところでぐちゃぐちゃした言い方をしています。
> To express this concept, we define a new term, for use in this document:
HTTP/1.1 仕様書での用語遣いの失敗を修正するのにはもう遅すぎますので、
代わりにこの文書で使用するために新しい用語を定義します。
>
:instance:
The entity that would be returned in a status-200
response to a GET request, at the current time, for
the selected variant of the specified resource, with
the application of zero or more content-codings, but
without the application of any instance manipulations
(see below) or transfer-codings.
:実現値:
特定の[[資源]]の選択された[[変体]]について、
[CODE(HTTP)[[[GET]]]] [[要求]]に対する[[状態]]
[CODE(HTTP)[[[200]]]] の[[応答]]で、現時点において返されるであろう、
零個以上の[[内容符号化]]を適用した、
[[実現値操作]]や[[転送符号化]]は適用していない[[実体]]。
> It is convenient to think of an entity tag, in HTTP/1.1, as being
associated with an instance, rather than an entity. That is, for a
given resource, two different response messages might include the
same entity tag, but two different instances of the resource should
never be associated with the same (strong) entity tag.
HTTP/1.1 の[[実体札]]は、実体と関連付けられていると考えるよりは、
実現値と関連付けられていると考えた方が便利です。
すなわち、ある資源について、二つの異なる[[応答メッセージ]]は同じ実体札を返すかもしれませんが、
その資源の二つの異なる実現値は決して同じ (強い) 実体札に関連付けられるべきではありません。
]FIG]