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 で、要求メッセージ又は応答メッセージの中に囲まれていてもよい。 要求又は応答の荷物として転送される情報。 実体は実体頭欄の形でメタ情報を含み、 実体本体の形で内容を含む。

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.

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

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 サーバー及びクライアントの慣習を肯定するために、注意深く選びました。

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 への串と関門も、何らかの変換が必要かもしれないので差異に注意する必要があります。

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