6.4 Header Fields
6.4.0 Introduction
The header fields listed in this clause shall be supported by all entities of the oneM2M system when using HTTP binding. Any other unrecognized HTTP headers shall be ignored by the HTTP client and server.
6.4.1 Host
The Host header shall be present in each HTTP request message.
While the Request-Target indicates a target resource on the Hosting CSE, the Host header indicates the FQDN or IP address of the Receiver CSE of the next hop in multi-hop communication scenarios. Therefore, the Request-Target is not changed but the Host header is changed each time when a request is forwarded to the next hop CSE.
When no HTTP proxy is used, the Host header shall be set as one of the pointOfAccess attribute values of the Receiver(i.e. pointOfAccess attribute of the corresponding <remoteCSE> resource). Selection of the appropriate Receiver is described in oneM2M TS-0004 [3]. In this case the origin-form of target URI shall be used (see clause 6.2.2).
If the HTTP request message is sent to a HTTP proxy rather than to the next hop CSE, the Host header shall be set to the FQDN or IP address of the proxy. In this case the absolute-form of target URI shall be used (see clause 6.2.2).
6.4.2 Accept
The Originator may use the Accept header to indicate which media types are acceptable for the response. The Accept header shall be mapped to a set of media types among "application/xml", "application/json", "application/cbor" or the oneM2M defined media types defined in clause 6.7 of oneM2M TS-0004 [3]. Note that some of the oneM2M defined media types defined in clause 6.7 of oneM2M TS-0004 [3] are not applicable for the response. Note that this information is not included in a request primitive.
6.4.3 Content-Type
Any HTTP request or response containing message-body shall include the Content-type header set to one of "application/xml", "application/json", or the oneM2M defined media types defined in clause 6.7 of oneM2M TS-0004 [3].
Content-Type of the HTTP response should be chosen by the Hosting CSE considering the Accept header given in the HTTP request.
The value of the Resource Type primitive parameter, which is present in Create request primitives only, shall be appended to the Content-type of the corresponding HTTP request message in the form ty=value, separated by a semicolon character. A valid Content-Type header in this case looks e.g. as follows:
Content-Type: application/vnd.onem2m-res+xml; ty=3
application/vnd.onem2m-res+json; ty=3
application/vnd.onem2m-res+cbor; ty=3
6.4.4 Content-Location
The Content-Location header of the HTTP response to a Create request shall be set to the URI of the created resource, if this URI is present in the Content parameter of the Create response primitive. See clause 7.3.3.12 "Create a success response" in oneM2M TS-0004 [3].
6.4.5 Content-Length
If message-body is included into HTTP request or response messages, the Content-Length header shall be included indicating the length of the message-body in octets (8-bit bytes).
6.4.6 Etag
A response primitive sent in reply to a resource retrieval request primitive should include an Etag header [8] in combination with the resource representation in the HTTP message body.
Etag facilitates the use of conditional requests (i.e. using the if-match and if-none-match HTTP headers) [8].
If a CSE supports the Etag header, then the CSE shall support conditional requests compliant with IETF RFC 7232 [8].
6.4.7 X-M2M-Origin
The X-M2M-Origin header shall be mapped to the From parameter of request and response primitives and vice versa, if applicable.
6.4.8 X-M2M-RI
The X-M2M-RI header shall be mapped to the Request Identifier parameter of request and response primitives and vice versa.
6.4.9 Void
6.4.10 X-M2M-GID
The X-M2M-GID header shall be mapped to the Group Request Identifier parameter of request primitives and vice versa, if applicable.
6.4.11 X-M2M-RTU
The X-M2M-RTU header shall be mapped to the notificationURI element of the Response Type parameter of request primitives and vice versa, if applicable. If there are more than one value in the element, then the values shall be combined with "&" character.
6.4.12 X-M2M-OT
The X-M2M-OT header shall be mapped to the Originating Timestamp parameter of request and response primitives, and vice versa, if applicable.
6.4.13 X-M2M-RST
The X-M2M-RST header shall be mapped to the Result Expiration Timestamp parameter of request and response primitives, and vice versa, if applicable.
6.4.14 X-M2M-RET
The X-M2M-RET header shall be mapped to the Request Expiration Timestamp parameter of request primitives and vice versa, if applicable.
6.4.15 X-M2M-OET
The X-M2M-OET header shall be mapped to the Operation Execution Time parameter of request primitives and vice versa, if applicable.
6.4.16 X-M2M-EC
The X-M2M-EC header shall be mapped to the Event Category parameter of request and response primitives, and vice versa, if applicable.
6.4.17 X-M2M-RSC
The X-M2M-RSC header in a HTTP response message shall be mapped to the Response Status Code parameter of response primitives and vice versa (e.g. Response Status Code 4000 and 4102 are mapped to HTTP Status Code 400 in the table 6.3.2-1).
6.4.18 X-M2M-ATI
The X-M2M-ATI header in a HTTP response message shall be mapped to the Assigned Token Identifiers parameter of response primitives and vice versa.
The format of the X-M2M-ATI header shall be represented as a sequence of lti-value:tkid-value pairs separated by a colon ":' and multiple pairs separated by '+' character.
For example, if the XML representation of the Assigned Token Identifiers parameter is given as (using short element names):
<ati>
<ltia>
<lti>lti-value1</lti>
<tkid>tkid-value1</tkid>
</ltia>
<ltia>
<lti>lti-value2</lti>
<tkid>tkid-value2</tkid>
</ltia>
...
</ati>
the header would look as follows:
The data type m2m:dynAuthlocalTokenIdAssignments of the Assigned Token Identifiers parameter is defined in clause 6.3.5.43 of TS-0004 [3].
6.4.19 Authorization
If a request primitive includes a Tokens parameter it shall be mapped to the Authorization header.
The Tokens primitive parameter is represented as a space separated list of JSON Web Signature (JWS) and JSON Web Encryption (JWE) strings in Compact Serialization format of datatype m2m:dynAuthJWT as defined in clause 6.3.3 of TS-0004 [3].
When mapped into the Authorization header, each individual token in the Tokens primitive parameter shall be separated by '+' character.
For example, if the Tokens parameter consists of a list of two JWS/JWE Tokens,
eyJ0eXAiOiJK.eyJpc3MiOiJqb2UiLA0KIC.dBjftJeZ4CVP
eyJ0eXAiOiJK.eyJpc3MiOiJqb2UiLA0KIC.dBjftJeZ4CVP.5eym8TW_c8SuK.SdiwkIr3a.XFBoMYUZo
the Authorization header looks as follows:
Authorization: eyJ0eXAiOiJK.eyJpc3MiOiJqb2UiLA0KIC.dBjftJeZ4CVP+ eyJ0eXAiOiJK.eyJpc3MiOiJqb2UiL
A0KIC.dBjftJeZ4CVP.5eym8TW\_c8SuK.SdiwkIr3a.XFBoMYUZo
The line break in the above example is for illustrative purposes and shall not be included into the Authorization header.
6.4.20 X-M2M-CTS
The X-M2M-CTS header shall be mapped to the Content Status parameter of response primitives and vice versa, if applicable.
6.4.21 X-M2M-CTO
The X-M2M-CTO header shall be mapped to the Content Offset parameter of response primitives, and vice versa, if applicable.
6.4.22 X-M2M-RVI
The X-M2M-RVI header shall be mapped to the Release Version Indicator parameter of request and response primitives, and vice versa.
6.4.23 X-M2M-VSI
The X-M2M-VSI header shall be mapped to the Vendor Information parameter of request and response primitives, and vice versa.
6.4.24 X-M2M-AS
If a request primitive includes an Authorization Signatures parameter, it shall be mapped to the X-M2M-AS header.
The Authorization Signatures primitive parameter is represented as a space separated list of URL-safe base64 encoded (base64url)) strings of datatype m2m:signatureList as defined in clause 6.3.3 of TS-0004 [3].
When mapped into the X-M2M-AS header, each individual signature in the Authorization Signatures primitive parameter shall be separated by '+' character.
For example, if the Authorization Signatures parameter consists of a list of two elements,
i6watmQQQ1y3GB-VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0_gyTE96639In0FZFY2_rvP-_bMJ01EArmKZsR5VW3rwoPxw==
the X-M2M-AS header looks as follows:
X-M2M-AS: i6watmQQQ1y3GB-VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==+
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0_gyTE96639In0FZFY2_rvP-_bMJ01EarmKZsR5VW3rwoPxw==
The line break in the above example is for illustrative purposes and shall not be included into the X-M2M-AS header. Whitespace characters are insignificant and should not be included into the header.
6.4.25 X-M2M-ASRI
The X-M2M-ASRI header in a HTTP response message shall be mapped to the Authorization Signature Request Information parameter of response primitives and vice versa, if applicable.
6.4.26 X-M2M-OMR
The X-M2M-OMR header shall be mapped to the Ontology Mapping Resources parameter of request primitives and vice versa, if applicable. The format of the oneM2M-OMR header shall be represented as a sequence of oneM2M resource identifiers separated by a '+'.
6.4.27 X-M2M-MSU
The X-M2M-MSU header shall be mapped to the M2M Service User parameter of request and response primitives, and vice versa, if applicable.
6.4.28 X-M2M-PRPI
The X-M2M-PRPI header shall be mapped to the Primitive Profile Identifier parameter of request primitives, and vice versa.