Content for  TS 29.500  Word version:  19.0.0

A request from an HTTP client (i.e. a service request from an NF service consumer, or a notification request from an NF service producer) may traverse one or more SCPs and/or SEPPs and may fail at an SCP, SEPP or at the HTTP server. The HTTP client should be able to figure out whether the request failed at its next hop SCP or SEPP, or at the HTTP server, e.g. to be able to adapt its behaviour for the on-going request or subsequent request accordingly. For instance, the HTTP client may retry the request or send subsequent requests towards the same HTTP server via a different SCP or SEPP if an SCP or SEPP rejected a request due to insufficient resources, or towards a different HTTP server (via the same or a different SCP or SEPP) if the HTTP server rejected the request due to insufficient resources. If the SCP or HTTP client receives an error response including the 3gpp-Sbi-Response-Info header with the "no-retry" parameter set to "true", the SCP or HTTP client shall consider that the request cannot be served anywhere and should not retry the request at the original HTTP server instance or at any other alternative HTTP server instance; the SCP shall forward the error response to the HTTP client including the 3gpp-Sbi-Response-Info header. When receiving an error response, the HTTP client should be able to figure out whether the SCP attempted to retransmit the request to an alternative HTTP server instance. To enable so, if the SCP attempted to retransmit the request to an alternative HTTP server instance, it shall indicate so in the error response by including the 3gpp-Sbi-Response-Info header with the "request-retransmitted" parameter set to "true" and by optionally including the list of NF instances, NF sets, NF service instances or NF service sets that it attempted. The SCP may indicate in the error response that it did not attempt to retransmit the request to an alternative HTTP server instance by including the 3gpp-Sbi-Response-Info header with the "request-retransmitted" parameter set to "false". The HTTP client may use this information to determine whether it may retransmit the request to an alternative HTTP server instance. If an SCP or SEPP receives an error response including the 3gpp-Sbi-Response-Info header with the "request-retransmitted" parameter set to "true" (e.g. in a scenario with two SCPs between the HTTP client and HTTP server), the SCP (if it does not reselect a target NF) or SEPP shall forward the error response with the the 3gpp-Sbi-Response-Info header unmodified towards the HTTP client; alternatively, the SCP may reselect a target NF and, if the NF reselection fails, the SCP may add the list of of NF instances, NF sets, NF service instances or NF service sets that it attempted in the 3gpp-Sbi-Response-Info header returned in the error response towards the HTTP client.

To enable an HTTP client to determine the originator of an HTTP error response, the originator of an error (e.g. HTTP server, SCP or SEPP) should include a Server header in the HTTP error response with the following information:

• the type of the NF or network entity generating the error, set to the NFType value as defined in clause 6.1.6.3.3 of TS 29.510, e.g. "SCP", "SEPP", "SMF";
• the identity of the NF or network entity generating the error, set to the FQDN of the SCP or SEPP, or to the NF Instance ID of the HTTP server.

EXAMPLE 1: EXAMPLE 2: EXAMPLE 3: The presence of a Server header set to the next hop SCP or SEPP or to the HTTP server in an HTTP error response shall be an indication for the HTTP client that the next hop SCP or SEPP or the HTTP server is the originator of the error. If neither the target NF nor alternative NFs that the SCP tries to (re)select based on the Routing Binding Indication or Discovery headers are reachable, the SCP shall return a HTTP 504 Gateway Timeout response including the "problemDetails" with the "cause" attribute set to "TARGET_NF_NOT_REACHABLE" and the Server header which is set to the FQDN of the SCP. If the cSEPP receives the HTTP request from the NF with "encBlockIndex" included as specified in clause 5.9.3.2 of TS 33.501, the cSEPP shall return a HTTP 400 Bad Request response including the "problemDetails" with the "cause" attribute set to "MANDATORY_IE_INCORRECT" or "OPTIONAL_IE_INCORRECT" and the "invalidParams" attribute indicates the incorrect IE. The Server header which is set to the FQDN of the cSEPP shall also be returned. If the SCP cannot fulfill a service request due to NRF related errors, the SCP shall originate an error towards the HTTP client as follows:

• If the NRF is not reachable, the SCP shall reject the request with a 504 Gateway Timeout including the "problemDetails" with the "cause" attribute set to "NRF_NOT_REACHABLE";
• If the NRF rejected an NF discovery request with a 5xx or 429 response, the SCP shall reject the request with a 502 Bad Gateway including the "problemDetails" with the "cause" attribute set to "NF_DISCOVERY_ERROR";
• If the NRF rejected an NF discovery request with a 4xx response, the SCP shall reject the request with a 4xx response including the "problemDetails" with an appropriate "cause" attribute (e.g. same response code and cause as received from the NRF).
• If the NRF returned a NF Discovery 200 OK response without any NF service producer matching the query parameters, the SCP shall reject the request with a "400 Bad Request" and the protocol error "NF_DISCOVERY_FAILURE" as specified in clause 6.10.6;
• see also clause 6.10.11.2 for SCP error handling requirements for errors due to NF service access authorization.

In either case, the SCP shall include the Server header in the error response set with its own identity (i.e. SCP FQDN) as specified in this clause.

To enable an HTTP client to determine the originator of an HTTP error response, e.g. when an HTTP server does not include a Server header in an HTTP error response, the SCP or SEPP that forwards the HTTP error response towards the HTTP client shall include a Via header in the HTTP error response with the following information:

• the received-protocol portion of the Via header as defined in Section 7.6.3 of RFC 9110;
• the type of the network entity forwarding the error, in the received-by portion formatted according to Table 5.2.2.2-2, set to the NFType value as defined in clause 6.1.6.3.3 of TS 29.510, i.e. "SCP" or "SEPP";
• the identity of the network entity forwarding the error, in the received-by portion formatted according to Table 5.2.2.2-2, set to the FQDN of the SCP or SEPP.

EXAMPLE 1: EXAMPLE 2: The presence of a Via header set to the next hop SCP or SEPP in an HTTP error response shall be an indication for the HTTP client that the next hop SCP or SEPP is not the originator of the error. A SEPP shall forward unmodified HTTP status codes and application errors that it receives.

An HTTP request sent using indirect communication may be redirected either to a different target NF service instance (from a same NF service set or NF set) or to a different SCP. When an HTTP server or SCP redirects an HTTP request (i.e. service request or notification/callback request) to a different target NF service instance, the URI of the target NF service instance towards which the request is redirected shall be given by the Location header field of the 307 Temporary Redirect or 308 Permanent Redirect response. When redirecting a request to a different NF instance (e.g. in a same NF set), the NF (service) instance ID of the target NF (service) instance towards which the request is redirected should be indicated in the 3gpp-Sbi-Target-Nf-Id header of the 307 Temporary Redirect or 308 Permanent Redirect response; it may be indicated otherwise (e.g. when redirecting a request to a different NF service instance of the same NF instance and overload control is to be performed per NF service instance). The HTTP client should then send the HTTP request towards the new target NF service instance using the same or a different SCP. The SCP shall forward a 3xx redirect response towards the HTTP client, if the URI in the Location header of the 3xx redirect response contains a different URI path than the URI path that was sent in the request to the HTTP server. In other cases, based on local policies, when appropriate (e.g. HTTP request creating a resource), the SCP may send the HTTP request towards the new target NF service instance instead of forwarding the 307/308 response to the HTTP client; in such a case, the SCP shall include the 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the target URI in the response message sent to the HTTP client, if no Location header is included in the response received from the new target NF service instance, according to the requirements specified in clause 6.10.4. An SCP may redirect an HTTP request towards a different SCP by sending a 307 Temporary Redirect or 308 Permanent Redirect response to the HTTP client including a RedirectResponse data structure (see TS 29.571) with the cause attribute set to "SCP_REDIRECTION" and with the targetScp attribute indicating the apiRoot of the SCP towards which the request is redirected. In this scenario, the 307 Temporary Redirect or 308 Permanent Redirect response shall include a Location header field where the content of the Location header field is implementation specific. The HTTP client should then send the HTTP request towards the target NF service instance using the SCP indicated in the 307 or 308 response; when doing so, the HTTP client shall ignore the information received in the Location header field if it receives a 307 Temporary Redirect or 308 Permanent Redirect response with the cause attribute set to "SCP_REDIRECTION" and including a Location header field, and it shall use the apiRoot included in targetScp IE as the apiRoot of the request URI to retransmit the HTTP request message via the alternative SCP. A SEPP may redirect an HTTP request towards a different SEPP over a non-N32 interface by sending a 307 Temporary Redirect or 308 Permanent Redirect response to the HTTP client including a RedirectResponse data structure (see TS 29.571) with the cause attribute set to "SEPP_REDIRECTION" and with the targetSepp attribute indicating the apiRoot of the SEPP towards which the request is redirected. In this scenario, the 307 Temporary Redirect or 308 Permanent Redirect response shall include a Location header field where the content of the Location header field is implementation specific. The HTTP client should then send the HTTP request towards the target NF service instance using the SEPP indicated in the 307 or 308 response; when doing so, the HTTP client shall ignore the information received in the Location header field if it receives a 307 Temporary Redirect or 308 Permanent Redirect response with the cause attribute set to "SEPP_REDIRECTION" and including a Location header field, and it shall use the apiRoot included in targetSepp IE as the apiRoot of the request URI to retransmit the HTTP request message via the alternative SEPP.

For indirect communications, request messages may be forwarded through multiple SCPs. In case of misconfiguration or error processing on intermediate SCPs, request messages may be relayed via unexpected paths or trapped in loops. The following two optional solutions may be used to enable the SCPs to detect and handle dead looping when relaying request messages in the network with indirect communication.

If Message Forwarding Depth Control is enabled, an HTTP client, or an SCP if the 3gpp-Sbi-Max-Forward-Hops header is not received in an incoming request, shall include in the request the 3gpp-Sbi-Max-Forward-Hops header with the node type "scp" indicating the maximum number of allowed intermediate SCPs to relay the message, before reaching the target HTTP server. When forwarding a request that includes the 3gpp-Sbi-Max-Forward-Hops header with node type "scp" to a next hop SCP, the SCP shall check whether the value of the header is zero or not, then

• if the value of 3gpp-Sbi-Max-Forward-Hops header with node type "scp" is zero, the SCP shall reject the request with the HTTP status code "502 Bad Gateway" and the protocol error "MAX_SCP_HOPS_REACHED";
• otherwise, the SCP shall decrement the value of the 3gpp-Sbi-Max-Forward-Hops header with node type "scp" by 1 before forwarding the request.

The Via header shall be inserted by HTTP proxies, SCPs and SEPPs when relaying an HTTP message (see clause 5.2.2.2). Upon receiving a request message, if Loop Detection through Via header is enabled, the SCP shall check the presence of itself, i.e. whether an "SCP-<SCP FQDN>" with its own FQDN is included in the Via headers received. If present, the SCP shall reject the request with the HTTP status code "400 Bad Request" and the protocol error "MSG_LOOP_DETECTED".