DICOM PS3.18 2024b - Web Services

8.5 Status Codes

Each response message contains a status-code.

The most common HTTP status codes used are listed in Table 8.5-1 Most of these codes are described in detail in [RFC7231]. IANA maintains the HTTP Status Code Registry [IANA HTTP Status Code Registry], which contains a complete list of registered status codes.

Table 8.5-1. Status Code Meaning





The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.



All Target Resource representations are contained in the payload. See [RFC7231] Section 6.3.1.



The request has been fulfilled and has resulted in one or more new resources being created. See [RFC7231] Section 6.3.2.



The request has been accepted for processing, but the processing has not been completed. The payload of this response should contain a Status Report. [RFC7231] Section 6.3.3.

The user agent may be able to inspect relevant resources to determine the status at some later time.


(Non-Authoritative Information)

The request was successful, but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy. See [RFC7230] Section 5.7.2 and [RFC7230] [RFC7231] Section 6.3.4.



The server has successfully fulfilled the request and there is no additional content to send in the response payload body. This should be the response when content is successfully uploaded, and the response has no payload.

For example, this status code is used in the response to a Conditional Retrieve request), when the Target Resource has not been modified. See [RFC7231] Section 6.3.5.


(Reset Content)

The server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.


(Partial Content)

The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the Target Resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field.

This status code shall only be used with Range Requests. See [RFC7233].


This status code was previously (erroneously) used to indicate that only some of a payload was stored.


The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent to fulfill the request.


(Moved Permanently)

The origin server has assigned the Target Resource to a new permanent URI, indicated in a Location header field.

This status is typically needed when the resource has been moved from one service to another, for example during a migration.


(See Other)

The origin the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which will provide a response to the original request.


(Not Modified)

The origin server has received a conditional GET or HEAD request that would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.

Client Error

The 4xx (Client Error) class of status code indicates that the user agent has erred.

For all these error codes,the origin server should return a payload containing an explanation of the error situation, and whether it is a temporary or permanent condition, except when responding to a HEAD request.


(Bad Request)

The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request …).



The request has not been fulfilled because it lacks valid authentication credentials for the service or Target Resource. The server generating a 401 response shall send a WWW-Authenticate header field ([RFC7235] Section 4.1) containing at least one challenge applicable to the server or Target Resource.



The origin server understood the request, but refused to authorize it (e.g., an authorized user with insufficient privileges). If authentication credentials were provided in the request, the server considers them insufficient to grant access. The origin server may respond with a 404 (Not Found) if not permitted to use this status code.


(Not Found)

The origin server did not find a representation for the Target Resource or is not willing to disclose that one exists. This might be a temporary condition. If the origin server knows that the resource has been deleted, the 410 (Gone) status code shall be returned rather than 404.


(Method Not Allowed)

The method in the request is known by the origin server but not supported by the target service or resource. The origin server shall include an Allow header field in a 405 response containing a list of the target service or resource's currently supported methods.


(Not Acceptable)

The Target Resource does not have a representation that would be acceptable to the user agent, per the content negotiation header fields in the request, and the server is unwilling to supply a default representation.

The origin server should return a payload that lists the available media types and corresponding resource identifiers.



The request could not be completed due to a conflict with the current state of the Target Resource. This code is used in situations where the user agent might be able to resolve the conflict and resubmit the request. The origin server should return a payload containing enough information for the user agent to recognize the source of the conflict.

In the DICOM context, this code might indicate that the origin server was unable to store any Instances due to a conflict in the request (e.g., unsupported SOP Class or Instance mismatch).



Access to the Target Resource is no longer available at the origin server and this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether the condition is permanent, the 404 (Not Found) status code should be used instead.


(Length Required)

The origin server refuses to accept the request because the Content-Length header field was not specified.


(Payload Too Large)

The server is refusing to process the request because the request payload is larger than the server is willing or able to process.


(URI Too Long)

The server is refusing to service the request because the request-target ([RFC7230] Section 5.3) is longer than the server is willing to interpret.


(Unsupported Media Type)

The origin server does not support the Content-Type in the request payload. This error typically occurs when the user agent is trying to create or update a resource.

The origin server should return a payload that lists the available media types and corresponding resource identifiers.


This is different from 406 (Not Acceptable).

Server Error

The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.

For all these error codes, the server should send an explanation of the error situation, and whether it is a temporary or permanent condition, except when responding to a HEAD request.


(Internal Server Error)

The server encountered an unexpected condition that prevented it from fulfilling the request.


(Not Implemented)

The server does not support the functionality required to fulfill the request.

In the DICOM context, this status code shall be used for SOP Class Not Supported errors.


(Service Unavailable)

The origin server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.


(HTTP Version Not Supported)

The origin server does not support, or refuses to support, the major version of HTTP that was used in the request message.

When a web server determines that a user agent should not receive certain information, the web server must choose the status code and the contents of a Status Report carefully. For example, local policy may dictate that the web service returns a 404 (Not Found) rather than a 401 (Unauthorized) status code to avoid allowing the user agent to infer the existence of a resource. The status code and payload of the response needs to be controlled by policy and context, balancing usability of the returned result against appropriate protection. See also [FHIR Access Denied] and [OWASP Information Leakage].

DICOM PS3.18 2024b - Web Services