payload

payload (HTTP)

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

仕様書

定義

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

[8] payload は、表現の一部又は全部を転送する場合もありますし、 関連するヘッダーの一部だけしか含んでいないこともあります >>5

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

意味

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

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

payload header

[10] 次のものが payload header として定義されています >>5。これは、 表現ではなく payload について記述するものである >>5 とされています。

[31] Content-* という似た名前を持っていても、 ここに分類されているものと表現メタデータに分類されるものとでは、 かなり性質が異なります。

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

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

payload body

[32] payload に含まれるデータの本体の部分のことを payload body といいます。 payload body はそのままメッセージ本体となることもあれば、 そうでないこともあります。

payload body の項を参照。

歴史

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

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

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

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

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

HTTP 実体

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

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

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

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

entity
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.]] The information transferred as the payload of a request or response. An entity consists of metainformation in the form of {1945} entity headers {2068,2616} entity-header fields and content in the form of an {1945} entity body entity-body, as described in section 7.
実体
データ資源又はサービス資源からの返答の特定の表現又は rendition で、要求メッセージ又は応答メッセージの中に囲まれていてもよい。 要求又は応答の荷物として転送される情報。 実体は実体頭欄の形でメタ情報を含み、 実体本体の形で内容を含む。

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

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

Full-Request メッセージと Full-Response メッセージは、要求方式や応答状態符号で特に制限されていない限り、 実体を転送しても構いません。 実体は実体頭欄実体本体 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

実体頭欄

7.2 Entity Body

entity-body

7.2.1 (Entity) Type

媒体型//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

メッセージ//長さ

HTTP 実体と MIME 実体の違い

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

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

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

[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

HTTP/1.0 HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 {1945} [7] {2616} [9] ) and the Multipurpose Internet Mail Extensions (MIME {1945} [5] {2616} [7] ) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 1521 MIME [7] RFC 2045 discusses mail, and HTTP has a few features that are different than from those described in RFC 1521 MIME 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 サーバー及びクライアントの慣習を肯定するために、注意深く選びました。

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 にはない習慣の幾つかを含むかもしれません。

This appendix describes specific areas where HTTP differs from RFC 1521 MIME RFC 2045. Proxies and gateways to strict MIME environments should 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 may {2616} might be required.

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

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

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

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

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

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

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

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

multipart/*//HTTP

RFC 2068・2616 (HTTP/1.1) 19.4.4; Introduction of Transfer-Encoding

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

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 がすべての message-body を積荷として輸送し、 その中に含まれているかもしれない内容や MIME 頭行を解釈しませんから、 行長制限と折畳み, 正統化, その他を含む MHTML のすべての変換に従います。

[27] RFC 3229 (差分符号化), RFC 3230 (要約) 用語定義より抜粋

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 では、 GET に対する応答メッセージは異なる分離された存在を有していません。 むしろ、応答メッセージは資源の現在の状態 (制約の集合の対象となる、変体) を記述しています。 HTTP/1.1 仕様書は「指定された資源の選択された変体についての現時点で GET 要求に対する応答で返されることになる値」 を記述する用語を提供していません。このために、 HTTP/1.1 仕様書でこの概念が必要なところでぐちゃぐちゃした言い方をしています。

To express this concept, we define a new term, for use in this document:

HTTP/1.1 仕様書での用語遣いの失敗を修正するのにはもう遅すぎますので、 代わりにこの文書で使用するために新しい用語を定義します。

(実現値参照)

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 の実体札は、実体と関連付けられていると考えるよりは、 実現値と関連付けられていると考えた方が便利です。 すなわち、ある資源について、二つの異なる応答メッセージは同じ実体札を返すかもしれませんが、 その資源の二つの異なる実現値は決して同じ (強い) 実体札に関連付けられるべきではありません。

実体タグ

[29] RFC 723x でも「実体タグ」はそのまま「実体」という用語を使っています。 しかしその「実体」とは何かは説明されていません。

[30]実体タグ」は、表現を区別するための識別子として説明されています。