Implement M1 Content Hosting Provisioning API #18
Comments
|
TS 26.512 CR0028r2 (Rel-17) went to SA#98-e as SP-221043. On the assumption that this will be approved this week by SA Plenary, have started to develop the M1 Content Hosting Provisioning API against this pre-publication V17.3.0 defintion. Created openAPI model source files based on this pre-published YAML definition. The newly generated code files have different signatures for functions to create |
|
I have added a comment to #19 noting that the entryPointPath should be checked for conformance using a regex compiled with the GNU C Library regex function |
|
Completed the uplift on #19. Now need to implement Create, Retrieve, Update and Destroy operations for |
|
Have implemented the the Create, Retrieve, Update and Destroy operations for the The following examples show that the operations are working as specified. However, the code still needs tidying up. Examples illustrating the operations
|
|
Started tidying up the code. Meanwhile, realised that I haven't tested the effect of the above M1 interface operations on the recent Application server (i.e Application Server from the "feature/uplift-to-ts26-512-v17-3-0" branch). So, performed tests by initiating operations through the M1 interface. The AF processed the operations that came through the M1 interface, populated its internal data structure and triggered corresponding operations through the M3 interface to the Application Server. So, tests worked as expected. Note that |
|
Have implemented part of the Sending back response to the M1 client is work in progress. |
|
Implemented the The example below demonstrates a successful purge operation on an already provisioned content Hosting Configuration resource: Below is an example of purge operation without regular expression: (works without |
Implementation design of purge operationThe M1 client sends a Purge request as a POST message. On receipt of this request, the Application Function populates a list that holds the context related to the purge operation such as the regular expression and resource identifier. It then sends a Purge request to the Application Server through the M3 interface. On receipt of a response from an Application Server, the Application Function checks the HTTP status code.
|
|
As the Application Function does not need to validate the optional ECMA regular expression request parameter prior to invoking the purge operation of the 5GMS AS instance(s), it is left to the Application Server to validate this expression and return an error if the expression is invalid. Currently, 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 to the Application Function. As a result, the Application Function sends a response with status 200 at M1. Raised a 5G-MAG/rt-5gms-application-server#52 so that the Application Server returns a 422 (Unprocessable Entity) response in the case of an invalid regex. On receipt of the response with status 422 at M3, the Application Function will trigger a new response at M1 indicating an error with status code 422. |
|
The Application Function is modified to handle the 422 response at M3 and trigger a new response at M1 indicating an error with status code 422. Haven't tested this with the AS as it is not yet modified to send 422 response. |
|
Tested the AF's handling of 422 response at M3 with the modified AS. The AF handles the 422 response provided by the AS at M3 and triggers a new response at M1 indicating an error with status code 422. Sample output: |
This looks wrong for an M1 error message from the Application Function. Looks like you're basing the M1 response on the M3 response object instead of the M1 request. @davidjwbbc has provided details of the parse error in |
|
@davidjwbbc also noticed that the Also clauses 6.2.1.1 and 6.2.3.4 of TS 26.512 specify
|
|
There's a simple hash function which hashes a buffer or string to an #include <gnutls/gnutls.h>
...
char result[128];
size_t result_len = sizeof(result);
gnutls_datum_t data;
data.data = input_buffer;
data.size = input_size;
gnutls_fingerprint(GNUTLS_DIG_SHA256, &data, result, &result_len);
/* SHA256 hash is in result and is result_len chars long */
...or #include <openssl/crypto.h>
#include <openssl/sha.h>
...
char result[SHA256_DIGEST_LENGTH];
char *hexstr;
SHA256(input_buffer, input_length, result);
hexstr = OPENSSL_buf2hexstr(result, SHA256_DIGEST_LENGTH);
/* SHA256 is in hexstr as a nul terminated string */
...
OPENSSL_free(hexstr);
... |
|
Passing back to @devbbc to deal with the |
Something at the back of my mind suggests that: and are considered equivalent in HTTP. So maybe the duplication permitted by the current Open5GS SBI library code is actually fine, @davidjwbbc? |
Multi-value headers (ones which in the spec are defined as ...would be interpreted as... |
|
Modified the AF so that M1 response is based on the M1 request as opposed to the M3 response object. Sample parsed error details shown below: Sample M1 response for correct regular expression: Sample M1 response for incorrect regular expression Other headers such as |
|
The I also can't decide if the instance should be |
That looks like the correct M1 path, @davidjwbbc. What are your doubts? |
|
@devbbc has coded ...but I'm thinking it should probably be... ...or even... ... to indicate the instance that caused the error. |
Oh, I see now. Yes, I agree that the So I agree that in this particular case it should be I think the only property that can safely be copied from the M3 error to the M1 error is probably |
|
For the |
That may be correct as of TS 26.512 V17.3.0. But we are discussing possible changes to that. |
|
There are a couple of limitations in using Open5GS functions to send error messages:
Hence, wrote custom functions, based on the original functions to handle error messages. With these functions, the error response now contains full path for |
Thinking about it, @devbbc, the Open5GS implementation is probably correct in the strictest sense of identifying the RESTful resource that was being manipulated by the operation. On reflection, I think we maybe ought not to change that aspect. Instead, we could make the human-readable detail more informative. For example:
We can chat separately about the problem you encountered populating |
|
By taking a copy of the
So, to fix 1 & 2 we need a similar routine to To fix 3 we will need a similar routine to |
|
@davidjwbbc: Please can we generalise the names of the three new functions to |
|
I think these functions can be defined in already existing |
|
Putting the new functions in their own new source files might be better for reuse elsewhere, though. |
|
The |
|
I've created a separate issue, #37, for the extra headers as they will be needed for more than just ContentHostingConfiguration responses. |
|
As I had previously implemented most of the functions, had to restructure them according to the recent comments. Now, the application function has |
|
Implemented The below sample output shows the response generated by this function: |
github-project-automation
bot
moved this from In Progress
to Done
in 5GMS: M1d Provisioning
|
Reopening for review |
|
There was no error handling when the ContentHostingConfiguration didn't pass verification (i.e. certificate Ids used in the distributionConfiguration match existing certificates for the provisioning session). I've modified the code to feed back when the verification fails and issue a 400 Bad Request response to the M1 client. |
|
Fixed a bug where the output of the JSON parser was not being checked, so malformed JSON caused the AF to crash. Tested this fixed version and the ContentHostingProvisioning interface looks good, closing this issue. |
github-project-automation
bot
moved this from Ready for review
to Done
in 5GMS: M1d Provisioning
Specification
Because there can only be zero or one Content Hosting Configuration associated with a parent Provisioning Session, the Content Hosting Configuration is identified by a fixed subresource path rather than by a UUID.
Additional implementation specification:
M1_ContentHostingProvisioning_purgeContentHostingCache: The 5GMS AF does not need to validate the optional ECMA regular expression request parameter prior to invoking the purge operation of the 5GMS AS instance(s) current serving the Content Hosting Configuration. However, the 5GMS AF should check for errors returned by each 5GMS AS instance when the M3 purge operation is invoked, and return a suitably non-specific error to the M1 invoker (e.g. title "Application Server encountered a problem when purging its cache" and description "Application Server encountered a problem when purging its cache for the regular expression 'XXXX'."). Any errors returned at M1 must be generated locally by the 5GMS AF so as not to leak any information about the number and nature of the 5GMS AS instances managed by the 5GMS AF.The following operations are out of scope for the present implementation:
M1_ContentHostingProvisioning_patchContentHostingConfiguration. (This operation is underspecified in Rel-17.) This operation should return a501 Not ImplementedHTTP response with a suitably descriptive human-readable error message in theProblemDetailsJSON response document.updateContentHostingConfigurationoperation.Relevant specifications
The text was updated successfully, but these errors were encountered: