CONTENTS
[ Back ] [ Next ]
Click Here to visit the home page belonging to
the creator of DCP and get access to other downloads, including a
white paper on forward compatible
design for the Internet.
| |
|
An entity is a particular representation or rendition of device data that may be enclosed
within a request or response message.
An entity consists of meta-information in
the form of entity headers and (usually) content in the form of an
entity body.
|
|
Entity header fields define optional
meta-information about the entity
body or, if no body is present, about the resource identified by the request.
Syntax
|
|
|
The content (if any) of an entity takes the form
of an entity body. Bodies are sent with requests
and responses in a format and encoding defined by
entityHeader fields (see
entity
type and
entity length).
Syntax
An entity body is included with a request message only when the
request method calls
for one. The presence of an entity body in a request is signaled by the inclusion of a
contentLength header field in the request message headers. DCP
requests containing an entity body must include a valid contentLength header field.
For response messages, whether or not an entity body is included with message is
dependent on both the request method and the response
code. All 1xx
(informational) and 300 Not Changed responses must not
include a body. All other responses must include an entity body or a contentLength header
field defined with a value of zero (0).
|
|
|
When an entity body is included with a message, the data
type of that body is determined via the header fields contentType
and contentEncoding. These define a two-layer, ordered
encoding model. The contentType
header specifies the media type of the underlying data. A
contentEncoding
header may
be used to indicate any additional content coding applied to the type (usually for the
purpose of data compression). The default for
the content encoding is none (i.e., the identity function).
Any DCP message containing an entity body should include a
contentType header field
defining the media type of that body. If and only if the media type is not given by a
contentType header, the recipient may
attempt to guess the media type via inspection of its content and/or the name extension(s)
of the URL used to identify the resource. If the media type remains unknown, the recipient
should treat it as type "application/octet-stream".
|
|
|
When an entity body is included with a message, the length
of that body may be determined in one of two ways for connection-oriented
MOS. If a contentLength header field is present, its value
in bytes represents the length of the entity body. Otherwise, the body length is
determined by the closing of the connection by the target for connection-oriented MOS.
Since connectionless
MOS does not establish a connection, a contentLength
header is required for connectionless MOS.
Closing a connection-oriented
MOS connection cannot be used to indicate the end of a
request body, since it leaves no possibility for the
target to send back a response.
Therefore, DCP requests containing an entity body must include a valid
contentLength header field whether they are connection-oriented MOS or connectionless MOS. If a request
contains an entity body and content length is not specified, and the target does not
recognize or cannot calculate the length from other fields, then the target should send a 400 Bad Request response.
|
|