Reject invalid CHC ingestConfiguration.baseURL

[ErikGaida]

Summary

This PR fixes validation of ingestConfiguration.baseURL in Content Hosting Configuration requests.

Close issue #186

[ErikGaida]

In rt-5gms-application-function/subprojects/rt-common-shared/open5gs-tools/openapi-generator-templates/c/model-body-object-defs.mustache, there is the following regex:

#define _OPENAPI_URI_REGEX "^" _OPENAPI_URI_RE_SCHEME ":" _OPENAPI_URI_RE_HIER_PART "(?:\?" _OPENAPI_URI_RE_QUERY ")?(?:#" _OPENAPI_URI_RE_FRAGMENT ")?"

An end of string anchor $ should be added at the end:

#define _OPENAPI_URI_REGEX "^" _OPENAPI_URI_RE_SCHEME ":" _OPENAPI_URI_RE_HIER_PART "(?:\?" _OPENAPI_URI_RE_QUERY ")?(?:#" _OPENAPI_URI_RE_FRAGMENT ")?$"

The model-body-object-defs.mustache template generates rt-5gms-application-function/src/5gmsaf/openapi/model/msaf_api_ingest_configuration.c, which this regex.

Adding the $ at the end of the regex would be the cleanest way to fix the bug. In fact, if we fix the regex this way, most of the other changes currently in this PR would become obsolete. However, since this template is located in rt-common-shared and used across multiple repositories, I am unsure about the potential side effects this change might have elsewhere.

Additionally, I noticed another issue in the same file:

#define _OPENAPI_URI_RE_PATH = "(?:" _OPENAPI_URI_RE_PATH_ABEMPTY "|" _OPENAPI_URI_RE_PATH_ABSOLUTE "|" _OPENAPI_URI_RE_PATH_NOSCHEME "|" _OPENAPI_URI_RE_PATH_ROOTLESS ")"

There is an = in the macro definition. I believe this will cause syntax errors when the macro is used in the C code.

[rjb1000]

I'm a bit confused here. The 422 Unprocessable Entity response was only intended for use with the operation to clear the Content Hosting cache using an invalid regular expression. I see references to the regular expression in #186. However, the main topic of that issue was a malformed base URL in the Content Hosting Configuration. In that error scenario, the appropriate response would be 400 Bad Request with a reason exposed in the ProblemDetails message body.

[ErikGaida]

I'm a bit confused here. The 422 Unprocessable Entity response was only intended for use with the operation to clear the Content Hosting cache using an invalid regular expression. I see references to the regular expression in #186. However, the main topic of that issue was a malformed base URL in the Content Hosting Configuration. In that error scenario, the appropriate response would be 400 Bad Request with a reason exposed in the ProblemDetails message body.

Thank you @rjb1000, that makes sense.

I interpreted the AS response as the status code the AF should also return, because the AS currently rejects the malformed baseURL with 422 Unprocessable Entity.

AS:
[2026-03-18 18:09:33 +0100] [27853] [INFO] 127.0.0.1:51358 - - [18/Mar/2026:18:09:33 +0100] "POST /3gpp-m3/v1/content-hosting-configurations/f737651e-22ec-41f1-9c13-8da79511cbf8 2" 422 178 "-" "-"

The AS-side reason for the 422 response is: #186 (comment)

Currently, the AF accepts the invalid CHC on M1 and forwards it to the AS over M3. The AS then rejects it with 422, which is why I initially thought the AF should also respond with 422.

1. I will revert the 422 response change in this PR and handle the malformed baseURL as 400 Bad Request instead.

2. Separately, I will prepare a PR for rt-common-shared to fix the URI regex. If that is fixed, the additional baseURL validation code in this PR should no longer be needed.

3. For this PR, I will focus on preventing the M3 retry loop. When the AS responds to the CHC POST with 405, 413, 414, 415, 422, 500, or 503, the AF currently keeps retrying the same POST indefinitely because the pending CHC upload remains queued. My proposed fix would be to clear the pending CHC upload request in these error cases, so the AF does not keep retrying it.

@rjb1000 Does this approach make sense to you, and are you okay with the steps above?

[rjb1000]

The definition of 422 Unprocessable Entity in section 15.5.21 of RFC 9110 implies that it is only valid for semantic failures of request bodies that are otherwise syntactically valid. The invalid base URL on this PR is borderline: the JSON document is syntactically fine (in other words, it is a processable entity), but one of the properties contains a URL that isn't syntactically valid.

I can see arguments in favour of both 422 Unprocessable Entity and 400 Bad Request. But, for the sake of simplicity, I think that I would go for the latter. Arguably, the 5GMSd AS would also have chosen the latter.

Currently, the AF accepts the invalid CHC on M1 and forwards it to the AS over M3. The AS then rejects it with 422, which is why I initially thought the AF should also respond with 422.

1. I will revert the 422 response change in this PR and handle the malformed baseURL as 400 Bad Request instead.

2. Separately, I will prepare a PR for rt-common-shared to fix the URI regex. If that is fixed, the additional baseURL validation code in this PR should no longer be needed.

3. For this PR, I will focus on preventing the M3 retry loop. When the AS responds to the CHC POST with 405, 413, 414, 415, 422, 500, or 503, the AF currently keeps retrying the same POST indefinitely because the pending CHC upload remains queued. My proposed fix would be to clear the pending CHC upload request in these error cases, so the AF does not keep retrying it.

@rjb1000 Does this approach make sense to you, and are you okay with the steps above?

That all sounds fine to me.