|
The various status codes for DCP responses are
defined in this section. The status code element of the 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. Each status code is described in this section. The main classes for status
codes are listed below.
Reference: Status Code Response Classes
2xx: Success
The action was successfully received,
understood, and accepted. |
|
|
|
The 1xx: Informational class of status code indicates a provisional response, consisting only of the status
line and optional headers, and is terminated by an empty
line. DCP does not define any 1xx status codes and they are not a valid response to a DCP request. However, they may be useful for experimental
applications which are outside the scope of this specification.
|
|
|
This 2xx: Successful class of status code indicates that the initiators's request was successfully received, understood, and accepted.
Reference: 2xx: Successful status codes and recommended reason phrases
Status
Code |
|
Reason
Phrase
|
| 200 |
= |
"OK"
|
| 201 |
= |
"OK, Pending"
|
| 202 |
= |
"OK, Keep Alive"
|
| 203 |
= |
"OK, Release"
|
|
|
The 200 status code
indicates that the request succeeded.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 200 Status Code
DCP/1.0 200 OK
The information
returned with the response is dependent on the method used in the request.
Reference: Information returned with a 200 response
| Method |
|
Response |
| get |
: |
A status line and header information along
with an entity
corresponding to the requested object property or reserved object are sent
in the response. |
| set |
: |
The response only contains a status line
and header information. Entity
bodies should not be sent in the
response. |
| call |
: |
A status line and header information along
with an entity
containing the return data of
the object method called are sent in the response. |
| event |
: |
A status line and header information along
with an entity
corresponding to the event are sent
in the response. |
| subscribe |
: |
The response only contains a status line
and header information. Entity
bodies should not be sent in the
response. |
| tether |
: |
The response only contains a status line
and header information. Entity
bodies should not be sent in the
response. |
| admin |
: |
The response only contains a status line
and header information. Entity
bodies should not be sent in the
response. |
|
|
The 201 status code
indicates that the request has been accepted and processing has
begun, but has not completed. The purpose of the 201 response
is to allow long-running processes to return data to the initiator over multiple responses
(and multiple connections on connection-oriented modes of
service), and to inform the initiator to
expect more responses pertaining to the original request.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 201 Status Code
DCP/1.0 201 OK, Pending
|
|
The 202 status code indicates that the request has been accepted for
processing and the session should be kept alive. This should be
used in response to requests that contain headers
that may indicate a session is terminating when keeping the session alive is
desired. The response information sent should conform to the same
guidelines as 200 responses.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 202 Status Code
DCP/1.0 202 OK, Keep Alive
|
|
The 203 status code
indicates that the request has been accepted for
processing and the session should be released. This should be
used in response to requests that contain headers
that may indicate a session is terminating when keeping the session alive is not
desired. The response information sent should conform to the same
guidelines as 200 responses.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 203 Status Code
DCP/1.0 203 OK, Release
|
|
|
The 3xx: Redirection class of status code indicates that further action
needs to be taken by the initiator agent in order to fulfill the request.
The action required may be carried out by the initiator agent without interaction with the user
if and only if the method used in the subsequent request is GET or SUBSCRIBE. An
initiator agent should
never automatically redirect a request more than 5 times, since such redirections usually
indicate an infinite loop.
Reference: 3xx: Successful status codes and recommended reason phrases
Status
Code |
|
Reason
Phrase
|
| 300 |
= |
"Not Changed"
|
| 301 |
= |
"Session Redirected"
|
|
|
The 300 status code
indicates that the initiator has performed a conditional get
request (see If-Changed-Since)
and access is allowed, but the property has not been modified since the date and time
specified in the If-Changed-Since header field, the target must
respond with this status code and not send an entity body to
the initiator.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 300 Status Code
DCP/1.0 300 Not Changed
|
|
The 301 status code
indicates that the target has specified an alternate location for the current session
and that any further requests made within the session
should be done using the alternate location. This allows the target to
specify another port or host for processing the remainder of the session.
The alternate location must be given by the location header
field.
Initiators should automatically re-link references to the alternate location
returned by the target. For locations involving alternate hosts, initiator
agents should be programmed to obtain confirmation prior to redirection from the
initiator when there is a potential for the initiator to expose sensitive
information.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 301 Status Code
DCP/1.0 301 Session Redirected
|
|
|
The 4xx: Initiator Error class of status code is intended for cases in which
the initiator seems to have erred. If the initiator has not completed the request when a 4xx code is received, it should immediately cease
sending data to the target. The target should include an entity
containing an explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any request
method.
Note: If the initiator is sending data, target implementations on connection-oriented
MOS (TCP specifically) should be careful to ensure that the initiator acknowledges receipt
of the packet(s) containing the response prior to closing the input connection. If the
initiator continues sending data to the target after the close, the target's controller
will send a reset packet to the initiator, which may erase the initiator 's unacknowledged
input buffers before they can be read and interpreted by the DCP application.
Reference: 4xx: Initiator Error status codes and recommended reason phrases
Status
Code |
|
Reason
Phrase
|
| 400 |
= |
"Bad Request"
|
| 401 |
= |
"Unauthorized"
|
| 402 |
= |
"Session Error"
|
| 403 |
= |
"Forbidden"
|
| 404 |
= |
"Not Found"
|
| 405 |
= |
"Method Not Allowed"
|
|
|
The 400 status code
indicates that the request could not be understood by the target
due to malformed syntax. The initiator should not repeat the request without
modifications.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 400 Status Code
DCP/1.0 400 Bad Request
|
|
The 401 status code
indicates that the request requires initiator access
authentication. The response must include a WWW-Authenticate header field containing a challenge applicable to
the requested resource. The initiator may repeat the request with a suitable Authorization header field. If the request already included
authorization credentials, then the 401 response indicates that authorization has been
refused for those credentials. If the 401 response contains the same challenge as the
prior response, and the initiator has already attempted authentication at least once,
then the initiator should be presented the entity that was given in
the response, since that entity may include relevant diagnostic information.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 401 Status Code
DCP/1.0 401 Unauthorized
|
|
The 402 status code
indicates that the request was understood by the target, but the
target has refused to process it due to the session
ID specified in the request (see the Session-ID
header). This may be used when an initiator tries to close a session that
does not exist, open a session with an ID that is already in use, or when
otherwise valid requests are denied due to the session ID specified.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 402 Status Code
DCP/1.0 402 Session Error
|
|
The 403 status code
indicates that the request was understood by the target, but the
target is refusing to fulfill it. Authorization will not help
and the request should not be repeated. If the target wishes to make public why the
request has not been fulfilled, it should describe the reason for the refusal in the entity body. This status code is commonly used when the target
does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 403 Status Code
DCP/1.0 403 Forbidden
|
|
The 404 status code
indicates that the target could not find anything matching the request
URI.
If the target does not wish to make this information available to the initiator,
the 403 status code can be used instead.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 404 Status Code
DCP/1.0 404 Not Found
|
|
The 405 status code indicates that the request method specified in the request line is not
permitted for the resource identified by the request URI. The response must include
an Allow header containing a list of valid methods for the
requested resource.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 405 Status Code
DCP/1.0 405 Method Not Allowed
|
|
|
The 5xx: Target Error class of status codes
indicates cases in which the target is aware that it has erred or is incapable of
performing the request. If the initiator has not completed the
request when a 5xx code is received, it should immediately cease sending data to the
target. The target should include an entity containing an
explanation of the error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method and
there are no required header fields.
Reference: 5xx: Target Error status codes and recommended reason phrases
Status
Code |
|
Reason
Phrase
|
| 500 |
= |
"Internal Target Error"
|
| 501 |
= |
"Not Implemented"
|
| 503 |
= |
"Service Unavailable"
|
|
|
The 500 status code indicates that the target encountered an unexpected condition which prevented it
from fulfilling the request.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 500 Status Code
DCP/1.0 500 Internal Target Error
|
|
The 501 status code indicates the target does not support the functionality required to fulfill the request. This is the appropriate response
when the target does not recognize the request method and is
not capable of supporting it for any resource.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 501 Status Code
DCP/1.0 501 Not Implemented
|
|
The 503 status code indicates that the target is currently unable to handle the request due to a temporary overloading or maintenance of the
target. The implication is that this is a temporary condition which will be alleviated
after some delay.
Note: The existence of the 503 status code does not imply that a target must use it
when becoming overloaded. Some targets may wish to simply refuse the connection.
Syntax
Reference: Recommended Reason Phrase
Example: Status Line with a 503 Status Code
DCP/1.0 503 Service Unavailable
|