Supported Headers

B Supported Headers

The following tables list the headers supported by NRF.

Supported 3GPP Custom Headers

Table B-1 Supported 3GPP Custom Headers

Custom Header Name	Description
`3gpp-Sbi-Message-Priority`	This header is used to specify the HTTP/2 message priority for 3GPP service-based interfaces. NRF supports this header for ingress requests, egress requests, forwarding scenarios, and roaming scenarios. NRF validates the priority value and applies configured priority mapping rules before forwarding or responding to requests.
`3gpp-Sbi-Callback`	This header is used to identify a particular type of callback, for example, notification. NRF uses this header while routing NFStatusNotify requests through SCP and Egress Gateway.
`3gpp-Sbi-Target-apiRoot`	This header contains the apiRoot of the target URI in a message request sent during indirect communication scenarios such as forwarding, roaming, and SCP routing procedures. NRF uses this header while routing egress requests through SCP, SLF, forwarding, and roaming flows.
`3gpp-Sbi-Discovery-target-nf-set-id`	This header identifies the target NF Set that the NRF should use as a filter during NF discovery. It limits the discovery result to NF instances that belong to the specified NF Set, enabling scoped and topology-aware selection.
`3gpp-Sbi-Client-Credentials`	This header is used by a consumer NF to send a Client Credential Assertion (CCA) to NRF during Access Token service operation. NRF validates JWT claims, X.509 certificate chains, NF instance identity, audience, and token expiry before issuing OAuth2 access tokens.
`3gpp-Sbi-Correlation-Info`	This header may contain correlation information, for example UE identity, SUPI, or GPSI, that may be used by operators for network management, troubleshooting, performance analysis, and subscriber tracing. NRF uses this header in enhanced error logging, NFDiscover procedures, and troubleshooting flows.

NRF also supports the HTTP standard headers. For more information, see 3GPP TS 29.500, Table 5.2.2.2-1.

Standard Headers Supported by NRF

Table B-2 Standard Headers Supported by NRF

Header Name	Description
Mandatory to Support HTTP Request Standard Headers
`Accept`	This header specifies acceptable response media types.If NRF receives this header in a request, it forwards it as is and does not perform any action on it.
`Accept-Encoding`	This header indicates the type of response content encoding, for example, GZIP, is acceptable in the response. If the received data is in GZIP format, NRF decompresses it if required and then compresses it to GZIP before forwarding it.
`Content-Length`	This header provides the anticipated size, as a decimal number of octets, for potential content.
`Content-Type`	This header indicates the media type of the associated representation.
`User-Agent`	This header identifies the NF type of the HTTP/2 client.
`Cache-Control`	This header is used in some HTTP/2 requests to provide the HTTP cache-control directives that the client can accept from the server. If NRF receives this header in a request, it forwards it as is and does not perform any action on it.
`If-Modified-Since`	This header is used in a conditional GET request to re-validate the server. This is used in conjunction with the LastModified server response header to retrieve content if the content has been modified from the cached version. If NRF receives this header in a request, it forwards it as is and does not perform any action on it.
`If-None-Match`	This header is used in a conditional GET request. This is used in conjunction with the ETag server response header to retrieve content if the tag value of the resource on the server differs from the tag value in the If-None-Match header. If NRF receives this header in a request, it forwards it as is and does not perform any action on it.
`If-Match`	This header is used in a conditional POST, PUT, DELETE, or PATCH request. This is used in conjunction with the ETag server response header to update or remove content if the tag value of the resource on the server matches the tag value in the If-Match header. If NRF receives this header in a request, it forwards it as is and does not perform any action on it.
`Via`	This header is inserted by HTTP proxies.NRF adds its own information in this header while forwarding.
`Authorization`	This header is used if OAuth 2.0 based access authorization with "Client Credentials" grant type is used as specified in subclause 13.4.1 of 3GPP TS 33.501 [17], clause 7 of IETF RFC 6749 [22] and IETF RFC 6750 [23].
Mandatory to Support HTTP Response Standard Headers
`Content-Length`	This header provides the anticipated size, as a decimal number of octets, for a potential content.
`Content-Type`	This header indicates the media type of the associated representation.
`Retry-After`	This header indicates the waiting period for the user agent before making a follow-up request.
`Content-Encoding`	This header indicates to the HTTP/2 client the content encodings, for example, gzip, applied to the resource representation beyond those inherent in the media type.
`Location`	This header is used in some responses to refer to a specific resource pertaining to the response.It is updated by NRF to an absolute URI if the location header in the response has a relative URI.
`Cache-Control`	This header is used in some responses, such as NRF responses to queries, to provide HTTP response cache control directives. The cache directives "no-cache", "no-store", "maxage", and "must-revalidate" values are supported. It is not supported by NRF and is forwarded as it is.
`Age`	This header is inserted by HTTP proxies when returning a cached response. This header conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server.It is not supported by NRF.
`Last-Modified`	This header is sent to allow for conditional GET with the IfModified-Since header. If NRF receives this header in a response, it forwards it as is and does not perform any action on it.
`ETag`	This header is sent to allow for a conditional GET with the If-None-Match header or a conditional POST, PUT, PATCH, or DELETE with the If-Match header. If NRF receives this header in a response, it forwards it as is and does not perform any action on it.
`Via`	This header is inserted by HTTP proxies.
`Allow`	This header is used to indicate methods supported by the target resource. If NRF receives this header in a response, it forwards it as is and does not perform any action on it.
`WWW-Authenticate`	This header is included when a producer NF rejects a request with a "401 Unauthorized" status code, for example, when a request is sent without an OAuth 2.0 access token or with an invalid OAuth 2.0 access token.