DICOM PS3.18 2020e - Web Services

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. Any message with a payload shall have a Content-Type header field that specifies the media type of the representation contained in the payload. The media type specifies whether the payload is single part or multipart (see Section 8.7). Any message with a payload should include a Content-Location header field. See [RFC7231] Section 3.1.2.2.

8.6.1 Payload Format

Payloads may be in either single part or multipart format depending on the media type.

8.6.1.1 Single Part Payload

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.

8.6.1.2 Multipart Payload

A message with a multipart payload contains one or more representations. 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. See Table 8.6.1-1 for other header fields occurring in multipart payloads.

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

int

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.

Each part in a multipart payload shall start with a Boundary header field, followed by a Content-Type header field. Other header fields may be included, such as Content-Location, and either the Content-Length or Content-Encoding header field, optionally followed by other header fields.

If a multipart payload contains 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.

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
--++++--

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

Mapping between IOD and HTTP message parts

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


DICOM PS3.18 2020e - Web Services