Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect error response status code for M1_ContentHostingProvisioning_purgeContentHostingCache operation #52

Closed
devbbc opened this issue Jan 5, 2023 · 3 comments · Fixed by #53
Assignees
Labels
bug Something isn't working
Milestone

Comments

@devbbc
Copy link

devbbc commented Jan 5, 2023

Description

If the purge regex pattern is invalid, the Application Server raises an exception and produces a local error log. However, the Application Server returns a response with status code 200 (OK) to the invoking client.

I think the response should have status code 422 (Unprocessable Entity) indicating that there is something wrong with the request message body.

Additional context

This bug arises from 5G-MAG/rt-5gms-application-function#18.

@rjb1000
Copy link
Contributor

rjb1000 commented Jan 5, 2023

I have created a Pull Request 5G-MAG/rt-common-shared#16 to add 422 (Unprocessable Entity) to the M3 API as a response to the purgeContentHostingCache operation.

@rjb1000
Copy link
Contributor

rjb1000 commented Jan 5, 2023

I have also raised 5G-MAG/Standards#40 to add this error response code (as well as a few others) to the purgeContentHostingCache operation in the M1 RESTful API specified in 3GPP TS 26.512.

@rjb1000
Copy link
Contributor

rjb1000 commented Jan 5, 2023

The ProblemDetails JSON structure conveyed as the body of the HTTP error response should clearly distinguish the various error cases:

  1. The request message body does not conform to the required x-www-form-urlencoded syntax.
  2. The form supplied in the request message body is syntactically correct, but does not include the required key.
  3. The form supplied in the request message body is syntactically correct, but includes unrecognised additional keys.
    • (Less important for the Application Server to check? Maybe it could simply ignore additional keys in the supplied form?)
  4. The form supplied in the request message body is syntactically correct, but the supplied regular expression does not conform to the required syntax.
    • e.g. the regular expression parser threw an error when attempting to compile it.

davidjwbbc added a commit to davidjwbbc/rt-5gms-application-server that referenced this issue Jan 16, 2023
@rjb1000 rjb1000 moved this from Backlog to In Progress in 5GMS: M3 link (AF to AS RESTful OpenAPI) Jan 17, 2023
@davidjwbbc davidjwbbc moved this from In Progress to Ready for review in 5GMS: M3 link (AF to AS RESTful OpenAPI) Jan 18, 2023
@davidjwbbc davidjwbbc linked a pull request Jan 18, 2023 that will close this issue
@davidjwbbc davidjwbbc moved this from Ready for review to Done in 5GMS: M3 link (AF to AS RESTful OpenAPI) Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

Successfully merging a pull request may close this issue.

3 participants