Add missing HTTP error status responses to M1_ContentHostingProvisioning_purgeContentHostingCache operation

[rjb1000]

Description

The YAML definition of the M1_ContentHostingProvisioning_purgeContentHostingCache operation does not currently specify HTTP response status codes for any error cases.

Suggested solution

It is proposed to add at least the following status codes:

• 404 (Not Found) to cover the error case where a non-existent Provisioning Session ID is cited in the request URL.
• 413 (Payload Too Large) to cover the error case where the POST message body (supplying the regular expression) is unreasonably large.
• 415 (Unsupported Media Type) to cover the error case where the POST message has an unrecognised Content-Type.
• 422 (Unprocessable Entity) to cover the error case where the POST message body (supplying a regular expression) is found to be syntactically invalid. For example:
  • The message body does not conform to the required x-www-form-urlencoded syntax.
  • The supplied regular express does not conform to the required syntax (e.g. the regular expression parser threw an error when attempting to compile it).

Additional context

This issue arose from the 5G-MAG/rt-5gms-application-server#52 and 5G-MAG/rt-5gms-application-function#18.

[davidjwbbc]

The 422 code may need adding to TS 29.500 Table 5.2.7.1-1 as it is not there at present.

[rjb1000]

The 422 code may need adding to TS 29.500 Table 5.2.7.1-1 as it is not there at present.

Not sure whether a change to TS 29.500 is required or not.

That specification is under the control of CT4 rather than SA4, so any change will require formal liaison.

SA4 has some wriggle room to define M1 and M3 as it pleases since neither reference point is formally a Service-Based Interface in the 5G System.

[rjb1000]

After internal discussion, we think it would be useful to the 5GMSd Application Provider invoking this operation to be able to distinguish between two success cases at M1:

• Request was fine, but no cache entries matched the regular expression.
  • 204 (No Content) with no response body.
• Request was fine, and some cache entries were purged.
  • 200 (OK) response including a JSON response body containing a single integer counting the total number of cache entries purged across the estate of 5GMSd AS instances that are currently configured to distribute the Provisioning Session in question.

[rjb1000]

@davidjwbbc: We should allow both 204 (No Content) and 200 (OK) at reference point M3 as well.

Please can you link to a suitable PR on 5G-MAG/rt-common-shared.

[rjb1000]

Contributions to 3GPP SA4#122 addressing this issue:

• TS 26.512:
  • Rel-16: CR0031 in S4-230041.
  • Rel-17: CR0032 in S4-230042.

[rjb1000]

Contributions revised and approved at 3GPP SA4#122 Closing Plenary:

• TS 26.512:
  • Rel-16: CR0031r1 in S4-230266.
  • Rel-17: CR0032r1 in S4-230267.

[rjb1000]

CR pack SP-250253 approved at SA#99 Plenary meeting in Rotterdam.

[rjb1000]

New specifications published by 3GPP MCC:

• TS 26.512:
  • V16.9.0.
  • V17.4.0.

(Transcription into equivalent ETSI Technical Specifications to follow in due course.)