DICOM PS3.18 2021c - Web Services

8.6 Payloads (Current)
Prev | 8 Common Aspects of DICOM Web Services | Next

## 8.6 Payloads

Both request and response messages may have message bodies. The message body (if any) of an HTTP message is used to carry the payload of the message. The message body is identical to the payload unless a content coding has been applied, as described in [RFC7230] Section 3.3.1. This Part of the Standard uses the term "payload" to denote the message body before any content coding has been applied to it.

A message may or may not have a payload. A payload may be empty; that is, its length is zero. If a message has no payload, then the message shall have neither Content-Encoding nor Content-Length header fields. If a message has a payload to which a transfer-coding has been applied, then the message shall have a Content-Encoding header field. If a message has a payload that has not had a transfer-coding applied, then the message shall have a Content-Length header field.

Any message containing a payload shall have appropriate Content Representation [RFC7231] Section 3.1 and Payload Header Fields [RFC7231] Section 3.3.

### 8.6.1 Payload Structure

Payloads contain representations. Payloads may be single part or multipart.

The message Content-Type header field contains a media type that includes multipart/related when the payload is multipart, otherwise the payload is single part.

#### 8.6.1.1 Single Part Payload

A message with a single part payload contains one representation that is described by the Content Representation Header Fields (see Section 8.4.3) contained in the message header.

A message with a single part payload shall have a Content-Type header field with a single part media-type (see Section 8.7.3).

#### 8.6.1.2 Multipart Payload

A message with a multipart payload contains one or more representations. Each representation goes in a separate part.

A message with a multipart payload shall have a Content-Type header field with a multipart media-type.

The media type of the root representation (see [RFC2387]) may be specified by the Content-Type header field of the message. If no root parameter is specified, then the root representation is the first representation in the payload.

Each part in a multipart payload shall start with a boundary string, followed by a Content-Type header field with a single part media type (see Section 8.7.3), followed by other fields as specified in Table 8.6.1-1. See also Figure 8.6-1. Other header fields may be included.

### Note

Understanding the nature of an encoded Bulkdata resource may depend on the corresponding Metadata reference to the bulkdataURI and is not necessarily implicit in the Content-Type header field.

The Content-Location is used to identify the specific resource (e.g. down to the level of a specific frame or instance or bulkdataURI) represented in this part. This allows the payload recipient to distinguish the parts, for example when each part contains a different frame of a requested multi-frame instance.

### Note

1. The metadata in the response of a Search Transaction is not considered a representation of a resource, so a Content-Location is not required.

2. In the case of a rendered resource, the Content-Location will identify the resource from which the rendering was generated.

Table 8.6.1-1. Multipart Header Fields

Name | Value | Usage | Description
--- | --- | --- | ---
Content-Type | media-type | M |
Content-Encoding | encoding | C | Shall be present if the response payload has a content encoding
Content-Length | uint | C | Shall be present if the response payload does not have a content encoding
Content-Location | url | C | Shall be present if the response payload contains a representation of a resource. See [RFC7231] Section 3.1.4.2.
Location | url | C | See [RFC7231] Section 7.1.2.

See Section 8.7.1 and [RFC7231].

The following is an example template of a multipart request or response message that has a multipart payload:

    request-line / response-line

    Content-Type: multipart-media-type CRLF

    Content-Location: "/" {/url} CRLF

    *(header-field CRLF)

    CRLF

    multipart-payload

The Content-Type header field shall have a multipart media-type. For example:

    Content-Type: multipart/related; type=DQ root-media-type DQ; boundary="---boundary---"

Where

    multipart-media-type
| is a media type defined by [RFC2387].
    root-media-type
| is a single part media type that specifies the media type of the root, typically the first part, in the payload. If the value of the type parameter and the root body part's content-type differ then the user agent's behavior is undefined.
    boundary
| specifies a string that acts as a boundary between message parts.

If a multipart payload contains representations of Metadata (see Section 8.7.3.3.1), and Bulkdata (see Section 8.7.3.3.2), then all Metadata message parts that reference a Bulkdata part shall precede the referenced Bulkdata part. The Content-Location of the Bulkdata part shall contain the corresponding BulkDataURI used in the referencing Metadata.

Figure 8.6-1 shows the correspondence between the IOD representation and a multipart payload.

Figure 8.6-1. Mapping between IOD and HTTP message parts

##### 8.6.1.2.1 Multipart Payload Syntax

The syntax of a multipart payload is:

    multipart-payload = 1*(DASH boundary CRLF part CRLF) DASH boundary DASH

Where

    DASH         = "--"
    boundary     = 0*69(bchar / SP) bchar
    bchar        = DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_"   ; The legal boundary characters
                 / "," / "-" / "." / "/" / ":" / "=" / "?"
    part         = Content-Type: media-type CRLF
                   Content-Location: url CRLF
                   (Content-Length: uint CRLF / Content-Encoding: encoding CRLF)
                   [Content-Description: text CRLF]
                   *(header-field CRLF)
                   CRLF
                   part-payload
    part-payload = *OCTET

For example, if the boundary is "++++", then a message payload containing three parts would be structured as follows:

    --++++CRLF

    Content-Type: media-type CRLF

    Content-Location: url CRLF

    (Content-Length: uint CRLF / Content-Encoding: encoding CRLF)

    [Content-Description: {description} CRLF]

    CRLF

    payload CRLF

    --++++CRLF

    Content-Type: media-type CRLF

    . . .

    payload CRLF

    --++++CRLF

    Content-Type: media-type CRLF

    . . .

    payload CRLF

    --++++--

Prev | Up | Next
8.5 Status Codes | Home | 8.6.2 DICOM Representations

DICOM PS3.18 2021c - Web Services