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.
| |
|
After receiving and interpreting a request message for a closed-loop
transaction, a
target responds in the form of one or multiple DCP response messages. The
information sent in a response is dependent on the request method.
Syntax
Note: Targets should not respond to requests that are made as part of open-loop
transactions.
The first line of a response message is the status line, consisting of the protocol
version followed by a numeric status code and its associated textual phrase, with each
element separated by sp characters. No
cr or lf
is allowed except in the final
crlf sequence.
Syntax
|
|
The status code element of a reponse
status line is a 3
digit integer result code of the attempt to understand
and satisfy the request. The status code is intended for use by automata.
The first digit of the status code defines the class of response. The last two digits
do not have any categorization role.
Reference: Status Code Response Classes
2xx: Success
The action was successfully received,
understood, and accepted. |
The individual values of the numeric status codes defined for DCP and status
code semantics are presented below.
Syntax
DCP status codes are extensible. DCP applications are not required to understand the
meaning of all registered status codes, though such understanding is obviously desirable.
However, applications must understand the class of any status code, as indicated by the
first digit, and treat any unrecognized response as being equivalent to the x00 status
code of that class. For example, if an unrecognized status code of 431 is received by the
initiator, it can
safely assume that there was something wrong with its request and treat the response as if
it had received a 400 status code. In such cases, initiator agents should present to the
user the entity returned with the response, since that entity is likely to include
human-readable information which will explain the unusual status.
|
|
The reason phrase of a response
status line is intended to give a short textual description
of the status code. The initiator is not required to examine or display the
reason phrase. The semantics for the reason phrase follow.
Syntax
A set
of recommended reason phrases is presented below.
Reference: Recommended Reason Phrases
Status
Code |
|
Reason
Phrase
|
| 200 |
= |
"OK"
|
| 201 |
= |
"OK, Pending"
|
| 202 |
= |
"OK, Keep Alive"
|
| 203 |
= |
"OK, Release"
|
| 300 |
= |
"Not Changed"
|
|
301 |
= |
"Session Redirected"
|
| 400 |
= |
"Bad Request"
|
| 401 |
= |
"Unauthorized"
|
| 402 |
= |
"Session Error"
|
| 403 |
= |
"Forbidden"
|
| 404 |
= |
"Not Found"
|
| 405 |
= |
"Method Not Allowed"
|
| 500 |
= |
"Internal Target Error"
|
| 501 |
= |
"Not Implemented"
|
| 503 |
= |
"Service Unavailable"
|
Note: Since the reason
phrases listed here are only suggested, they may be replaced by local equivalents without affecting the
protocol. |
|
|
Response header fields allow the target to
pass additional information about the response which cannot be placed in the
status line. These header fields give information about the target
and about further access to the resource identified by the request
URI.
Response header field names can be extended reliably only in combination with a change
in the protocol version. However, new or experimental header fields may be given the
semantics of response header fields if all parties in the communication recognize them to
be response header fields. Unrecognized header fields are treated as entity
header fields.
Syntax
|
|