106.txt

[1] [[HTTPメッセージ]]によって転送される対象を、[DFN[[[payload]]]] といいます。

* 仕様書

[REFS[
- [2] [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>
-- [5] [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.3>
]REFS]

* 定義

[3] 「[[payload]]」という語は [[HTTP]] 仕様書群全体で頻繁に登場しますが、
なぜかその明確な定義は含まれていません。

[8] [[payload]] は[[表現]]の一部又は全部を転送するものです [SRC[>>5]]。

[7] [[payload]] は、 [[payload body]] に加えて、関連する[[ヘッダー]]も含んでいる [SRC[>>5]] ようです。

[6] [[payload body]] は、[[メッセージ本体]]に含まれるデータ ([[転送符号化]]を[[復号]]したもの?)
を指しているようです。

* 意味

[4] [[HTTP]] 仕様書群の中でも、特に [[RFC 7231]] が [[payload]]
の意味を定義しています。

[9] [[payload]] の目的は、[[要求メッセージ]]においては[[要求メソッド]]の意味により、
[[応答メッセージ]]においては[[要求メソッド]]と[[状態符号]]の意味により決まります。

* payload header

[10] 次のものが [DFN[[[payload header]]]] として定義されています [SRC[>>5]]。これは、
[[表現]]ではなく [[payload]] について記述するものである [SRC[>>5]] とされています。
[FIG(short list)[
- [CODE(HTTP)@en[[[Content-Length:]]]]
- [CODE(HTTP)@en[[[Content-Range:]]]]
- [CODE(HTTP)@en[[[Trailer:]]]]
- [CODE(HTTP)@en[[[Transfer-Encoding:]]]]
]FIG]

[11] [[payload header]] は、 [CODE(HTTP)@en[[[HEAD]]]]
に対する[[応答]]には含めても構いませんし、含めなくても構いません。

;; [12] 含めたとしても、 [CODE(HTTP)@en[[[GET]]]] だったとした場合の値が含まれるのであり、
[CODE(HTTP)@en[[[HEAD]]]] への[[応答]]自体には[[メッセージ本体]]は含まれません。

* 歴史

[14] [[RFC 2616]] までは[DFN[[RUBYB[[[実体]]]@en[entity]]]]という用語が用いられていました。
[[実体]]は [[HTTP/1.0]] が [[MIME]] を取り込んだことによって [[MIME]]
から輸入した用語でした ([[MIME実体]]参照)。

[15] [[RFC 3229]]/[[RFC 3230]] は[RUBYB[[[実現値]]]@en[instance]]なる用語を導入しました。
両 [[RFC]] は[[実体]]という用語は [[MIME]] の[[電子メール]]と [[HTTP]]
とでは[[プロトコル]]の構造が異なるために意味が混乱していると指摘しています。

[13] [[RFC 723x]] は[[実体]]も[[実現値]]も採用せず、かわりに [[payload]]
という用語を使っています。ただし [[payload]] という語の明確な定義はなく、
また過去の[[実体]]や[[実現値]]という用語との差異も明確にはなっていません。

[17] [[実体]]は [[payload]] と近そうですが明確ではありません。

[16] [[実現値]]は、 [[RFC 723x]] の用語では「[[選択された表現]]」が近そうです。

** HTTP 実体

[18] [[HTTP]] の[[要求]]や[[応答]]で転送される[[資源]]の[[表現]]が[DFN[[RUBYB[[[実体]]][entity]]]]です。
構文的には [CODE(ABNF)[[[entity-header]]]] ([[実体頭欄]])
と [CODE(ABNF)[[[entity-body]]]] ([[実体本体]]) で構成されます。

HTTP 要求・応答メッセージは、必要なら実体を含めることができます。
(しかし場合によっては含めてはならないこともありますし、
含めなければならないこともあります。)

後に辞書的意味からこの概念に[Q[実体]]という語を充てたのは誤りだったとして[DFN[[[実現値]]]]という用語が導入されています。

[FIG(quote)[
[FIGCAPTION[
[19] RFC 1945 (HTTP/1.0) 1.2; RFC 2068・2616 (HTTP/1.1) 1.3 用語定義より抜粋
]FIGCAPTION]

>
:entity: [DEL[INS[{1945}]] A particular representation or rendition of a data resource, or reply from a service resource, that may be enclosed within a request or response message.]] [INS[The information transferred as the payload of a request or response.]]
An entity consists of metainformation in the form of [DEL[[INS[{1945}]] entity headers]] [INS[[INS[{2068,2616}]] entity-header fields]] and content in the form of an [DEL[[INS[{1945}]] entity body]] [INS[entity-body, as described in section 7]].

:実体: [DEL[データ資源又はサービス資源からの返答の特定の表現又は rendition で、要求メッセージ又は応答メッセージの中に囲まれていてもよい。]] [INS[要求又は応答の荷物として転送される情報。]]
実体は[[実体頭欄]]の形で[[メタ情報]]を含み、
[[実体本体]]の形で[[内容]]を含む。
]FIG]

[FIG(quote)[
[FIGCAPTION[
[20] RFC 1945 (HTTP/1.0) 7.; RFC 2068・2616 (HTTP/1.1) 7 Entity
]FIGCAPTION]

> [DEL[Full-]]Request and [DEL[Full-]]Response messages [DEL[may]] [INS[MAY]] transfer an entity [DEL[within some requests and responses]] [INS[if not otherwise restricted by the request method or response status code]].
An entity consists of [DEL[Entity-Header]] [INS[entity-header]] fields and [DEL[(usually) an Entity-Body]] [INS[an entity-body, although some responses will only include the entity-headers]].

[CODE(ABNF)[Full-Request]] メッセージと [CODE(ABNF)[Full-Response]]
メッセージは、[[要求方式]]や応答[[状態符号]]で特に制限されていない限り、
[DFN[[[実体]]]]を転送しても'''構いません'''。
実体は[[実体頭欄]]と[[実体本体]] [CODE(ABNF)[entity-body]] で構成します。
但し実体頭だけを含む応答もあります。

> In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.

この章では、[[送信者]]と[[受信者]]の両方が、
実体を誰が送信し誰が受信するかにより、
[[クライアント]]か[[サーバー]]のいずれかを指します。

* 7.1 Entity Header Fields
→[CODE(WikiPage)[[[実体頭欄]]]]
*7.2 Entity Body
→[CODE(WikiPage)[[[entity-body]]]]
** 7.2.1 (Entity) Type
→[CODE(WikiPage)[[[媒体型//HTTP]]]]
**RFC 1945 (HTTP/1.0)・RFC 2068 (HTTP/1.1) 7.2.2 Length; RFC 2616 (HTTP/1.1) 7.2.2 Entity Length
→[CODE(WikiPage)[[[メッセージ//長さ]]]]
]FIG]

** HTTP 実体と MIME 実体の違い

[22] [[MIME]] と [[HTTP]] 
では、[[実体]]の定義・扱いはほとんど同じながら、細かい点で幾つもの違いがあります。
その違いはどれも重要なものですから、よく理解しておかないと、
(いずれかに慣れていると) 
うっかりひどい間違いを犯してしまうかもしれません。

[23] また、 HTTP から派生した[[プロトコル]]である [[RTSP]]
や [[SIP]] は、ほとんど HTTP 
と同じながらも微妙な点でこれと異なったりしていますから、注意が必要です。

[24] >>23 これは MIME の標準化の失敗だよなあ。そりゃあ [[Usefor]] も HTTP も RTSP も SIP も「Internet Mail」ではないのは確かなのだけれども。

[FIG(quote)[
[FIGCAPTION[
[25] RFC 1945 (HTTP/1.0) C. Relationship to MIME; RFC 2068 (HTTP/1.1) Differences Between HTTP Entities and MIME Entities; RFC 2616 (HTTP/1.1) 19.4 Differences Between HTTP Entities and RFC 2045 Entities
]FIGCAPTION]

> [DEL[HTTP/1.0]] [INS[HTTP/1.1]] uses many of the constructs defined for Internet Mail (RFC
822 [DEL[[INS[{1945}]] [7] ]] [INS[[INS[{2616}]] [9] ]]) and the Multipurpose Internet Mail Extensions (MIME [DEL[[INS[{1945}]] [5] ]] [INS[[INS[{2616}]] [7] ]]) to
allow entities to be transmitted in an open variety of representations and
with extensible mechanisms. However, [DEL[[DEL[RFC 1521]] [INS[MIME [7] ]]]] [INS[RFC 2045]]
discusses mail, and HTTP has a few features that are different [DEL[than]] [INS[from]] those described in [DEL[[DEL[RFC 1521]] [INS[MIME]]]] [INS[RFC 2045]].  These differences were carefully chosen
to optimize performance over binary connections, to allow greater freedom in the
use of new media types, to make date comparisons easier, and to
acknowledge the practice of some early HTTP servers and clients.

[28] [[HTTP/1.1]] は Internet メイル ([[RFC 822]]) と多目的 
Internet メイル拡張 ([[MIME]]) 
に定義された構造の多くを、色々な種類の表現を使って拡張可能な仕組みの元で実体を転送するために使います。しかし、 [[RFC2045]]
はメイルを扱っていて、 HTTP には RFC 2045
で説明されているものとは違う機能が幾つかあります。
この違いは[[バイナリ]]接続での効率を最適化するため、新しい[[媒体型]]の使用を更に自由にするため、日付比較をより簡単にするため、幾つかの早期の
HTTP サーバー及びクライアントの慣習を肯定するために、注意深く選びました。

[DEL[
> At the time of this writing, it is expected that RFC 1521 will be
revised. The revisions may include some of the practices found in
HTTP/1.0 but not in RFC 1521.

執筆の時点では、 [[RFC1521]] が改訂されることが予定されています。
改訂版は HTTP/1.0 にあるのに RFC 1521 にはない習慣の幾つかを含むかもしれません。
]DEL]

> This appendix describes specific areas where HTTP differs from [DEL[[DEL[RFC 1521]] [INS[MIME]]]] [INS[RFC 2045]].
Proxies and gateways to strict MIME environments [DEL[should]] [INS[SHOULD]] be aware of
these differences and provide the appropriate conversions where
necessary. Proxies and gateways from MIME environments to HTTP also
need to be aware of the differences because some conversions [DEL[may]] [INS[[INS[{2616}]] might]] be required.

[26] この附属書では、 RFC 2045 とは違う HTTP 
の規定領域を説明します。厳密な MIME 
環境への[[串]]と[[関門]]は、この差異に注意し、必要であれば適切な変換を施す'''のが良いです'''。
MIME 環境から HTTP 
への串と関門も、何らかの変換が必要かもしれないので差異に注意する必要があります。

[INS[
注意: 注記のない修正点は RFC 1945 → RFC 2068 もの。
]INS]

*RFC 1945 (HTTP/1.0) D.2.7; RFC 2068 (HTTP/1.1) 19.4.7; RFC 2616 (HTTP/1.1) 19.4.1 MIME-Version
→[CODE(WikiPage)[[[MIME-Version]]]]
*RFC 1945 (HTTP/1.0) C.1; RFC 2068 (HTTP/1.1) 19.4.1; RFC 2616 (HTTP/1.1) 19.4.2 Conversion to Canonical Form
→[CODE(WikiPage)[[[text/*//正規化]]]]
*RFC 1945 (HTTP/1.0) C.2; RFC 2068 (HTTP/1.1) 19.4.2; RFC 2616 (HTTP/1.1) 19.4.3 Conversion of Date Formats
→[CODE(WikiPage)[[[HTTPの日付形式]]]]
*RFC 1945 (HTTP/1.0) C.3; RFC 2068 (HTTP/1.1) 19.4.3; RFC 2616 (HTTP/1.1) 19.4.4 Introduction of Content-Encoding
→[CODE(WikiPage)[[[Content-Encoding]]]]
*RFC 1945 (HTTP/1.0) C.4; RFC 2068 (HTTP/1.1) 19.4.4; RFC 2616 (HTTP/1.1) 19.4.5 No Content-Transfer-Encoding
→[CODE(WikiPage)[[[Content-Transfer-Encoding]]]]
*RFC 1945 (HTTP/1.0) C.5; RFC 2068 (HTTP/1.1) 19.4.5 HTTP Header Fields in Multipart Body-Parts
→[CODE(WikiPage)[[[multipart/*//HTTP]]]]
* RFC 2068・2616 (HTTP/1.1) 19.4.4; Introduction of Transfer-Encoding
→[CODE(WikiPage)[[[chunked]]]]
*RFC 1945 (HTTP/1.0) D.2.7; RFC 2068 (HTTP/1.1) 19.4.7; RFC 2616 (HTTP/1.1) 19.4.1 MIME-Version
→[CODE(WikiPage)[[[MIME-Version]]]]
*RFC 2616 (HTTP/1.1) 19.4.7 MHTML and Line Length Limitations
> HTTP implementations which share code with MHTML [45] implementations
need to be aware of MIME line length limitations. Since HTTP does not
have this limitation, HTTP does not fold long lines. MHTML messages
being transported by HTTP follow all conventions of MHTML, including
line length limitations and folding, canonicalization, etc., since
HTTP transports all message-bodies as payload (see section 3.7.2) and
does not interpret the content or any MIME header lines that might be
contained therein.

[[MHTML]] 実装と符号を共有する HTTP 実装は、 [[MIME]]
行長制限に注意する必要があります。 HTTP
はこの制限を有しませんから、 HTTP は長い行を[[折畳み]]ません。
HTTP で輸送される MHTML メッセージは、
HTTP がすべての [CODE(ABNF)[[[message-body]]]] を積荷として輸送し、
その中に含まれているかもしれない内容や MIME 頭行を解釈しませんから、
行長制限と折畳み, [[正統化]], その他を含む MHTML のすべての変換に従います。
]FIGCAPTION]

[FIG(quote)[
[FIGCAPTION[
[27] 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 仕様書での用語遣いの失敗を修正するのにはもう遅すぎますので、
代わりにこの文書で使用するために新しい用語を定義します。

[INS[
([[実現値]]参照)
]INS]

> 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]