Describe the bug
In the NRF endpoint GET nf-instances
, the optional parameters nf-type
and limit
are de-facto treated as mandatory.
If the limit
-Parameter is missing, a 400 Bad Request
is returned. If the limit parameter is present, but the
nf-type` parameter is missing, an empty result list is returned.
To Reproduce
Steps to reproduce the behavior:
- start a simple setup of free5gc
- request
GET http://<address>:port/nnrf-nfm/v1/nf-instances
- request
http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances?limit=10
Expected behavior
When called without limit
, the request should return all NF-instances or at least use a non-zero default limit.
When called without nf-type
, the request should not filter for NF type and return NFs of all types
curl output
As example, here is what a curl request returns for my setup. First the missing limit
parameter:
$ curl 'http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances' -H 'accept: application/json'
{"title":"Invalid Parameter","status":400,"detail":"strconv.Atoi: parsing \"\": invalid syntax"}
Second: the missing nf-type
-parameter:
$ curl 'http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances?limit=10' -H 'accept: application/json'
{"nfType":"","_link":{"item":null}}
In contrast to that, a working example:
$ curl 'http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances?limit=10&nf-type=AMF' -H 'accept: application/json'
{"nfType":"AMF","_link":{"item":[{"href":"http://nrf.free5gc.org:8000/nnrf-nfm/v1/nf-instances/5cce9dfa-6dbc-489f-8c19-a76d5a07ac2a"}]}}
Environment (please complete the following information):
- free5GC Version: 3.1.1
- OS: Arch Linux
- Kernel version: 6.1.2-arch1-1
- go version: go-1.14.4
- c compiler version (Option): gcc version 12.2.0
System architecture (Option)
The setup is a relatively basic docker setup using docker compose. The purpose of this setup is playing around with free5gc and doing research.
Additional context
I took a look at the code (internal/context/management_data.go
and internal/sbi/producer/nf_management.go
) and it looks like the issue would be relatively easy to fix. If someone here agrees that this report is an issue, I would
- check if the limit is present before trying to parse it
- set no limit to the mongodb-request if it is not set
- set no filter for the mongodb-request if
nf-type
is absent or empty
and make a pull-request.