6.1.2 Usage of HTTP

29.5033GPP5G SystemRelease 18Stage 3TSUnified Data Management Services

6.1.2.1 General

HTTP/2, as defined in IETF RFC 7540 [13], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].

HTTP/2 shall be transported as specified in clause 5.3 of 3GPP TS 29.500 [4].

HTTP messages and bodies for the Nudm_SDM service shall comply with the OpenAPI [14] specification contained in Annex A2.

6.1.2.2 HTTP standard headers

6.1.2.2.1 General

The usage of HTTP standard headers shall be supported as specified in clause 5.2.2 of 3GPP TS 29.500 [4].

6.1.2.2.2 Content type

The following content types shall be supported:

JSON, as defined in IETF RFC 8259 [15], signalled by the content type "application/json".

The Problem Details JSON Object (IETF RFC 7807 [16] signalled by the content type "application/problem+json"

JSON Merge Patch, as defined in IETF RFC 7396 [17], signalled by the content type "application/merge-patch+json"

6.1.2.2.3 Cache-Control

As described in IETF RFC 7234 [26] clause 5.2, a "Cache-Control" header should be included in HTTP responses except for non-cacheable resources (e.g. UeContextInSmsfData). If it is included, it shall contain a "max-age" value, indicating the amount of time in seconds after which the received response is considered stale.

The "max-age" value shall be configurable by operator policy.

6.1.2.2.4 ETag

As described in IETF RFC 7232 [25] clause 2.32, an "ETag" (entity-tag) header should be included in HTTP responses except for non-cacheable resources (e.g. UeContextInSmfData) to allow an NF Service Consumer performing a conditional request with "If-None-Match" header. If it is included, it shall contain a server-generated strong validator, that allows further matching of this value (included in subsequent client requests) with a given resource representation stored in the server or in a cache.

6.1.2.2.5 If-None-Match

As described in IETF RFC 7232 [25] clause 3.2, an NF Service Consumer may issue conditional GET request towards UDM by including an "If-None-Match" header in HTTP requests containing one or several entity tags received in previous responses for the same resource.

6.1.2.2.6 Last-Modified

As described in IETF RFC 7232 [25] clause 2.2, a "Last-Modified" header should be included in HTTP responses except for non-cacheable resources (e.g. SorAck) to allow an NF Service Consumer performing a conditional request with "If-Modified-Since" header.

6.1.2.2.7 If-Modified-Since

As described in IETF RFC 7232 [25] clause 3.3, an NF Service Consumer may issue conditional GET request towards UDM, by including an "If-Modified-Since" header in HTTP requests.

6.1.2.2.8 When to Use Entity-Tags and Last-Modified Dates

Both "ETag" and "Last-Modified" headers should be sent in the same HTTP response as stated in IETF RFC 7232 [25] clause 2.4.

NOTE: "ETag" is a stronger validator than "Last-Modified" and is preferred.

If the NF Service Producer included an "ETag" header with the resource then a conditional request for this resource shall be performed with the "If-None-Match" header.

6.1.2.3 HTTP custom headers

6.1.2.3.1 General

The usage of HTTP custom headers shall be supported as specified in clause 5.2.3 of 3GPP TS 29.500 [4].