wildcard character in resource uri

[rakeshksahu]

My project requirement demands that I shall be able to send runtime generated ids along with GET/PUT requests.

Current libcoap implementation exactly matches with the uri which I register while calling coap_resource_init(), and coap_register_handler().
If I add any string after that it will return error and will be rejected by library itself.

for example:
coap_resource_init(coap_make_str_const("hello/my"), 0);
it will pass request with hello/my only, but my requirement is to pass:
hello/my/1
hello/my/3
hello/my/55

I would like an option to match particular part of uri string

It can be introducing a wildcard entry while calling coap_resource_init. ex: coap_resource_init(coap_make_str_const("hello/my/*"), 0);
or
I can write a custom uri validator, which will give me more control to validate incoming URIs with registered resources.

If I can do the same in current implementation of libcoap then please suggest how.

[mrdeep1]

I would use coap_resource_unknown_init2(3). By default, it sets up the PUT handler, but a GET (and other types) handler(s) can be set up. The PUT etc. handlers do not have to set up new resources as per the example given at then end of the coap_resource_unknown_init2(3). You can abstract the requesting URI in the defined handler(s) using coap_resource_get_uri_path(3) and then decide what you want to do with it.

Having some form of resource pattern matching can be done, but it will introduce a degree of complexity. However, it will be in violation of RFC7252 3.2 Option Value Format

Note that here, and in all other places where UTF-8
encoding is used in the CoAP protocol, the intention is
that the encoded strings can be directly used and compared
as opaque byte strings by CoAP protocol implementations.

as the URI is passed across the wire in zero or more CoAP URI options and there needs to be opaque comparisons.

[rakeshksahu]

Hello!

I was trying out with example code in the repo.
GET requests from client get rejected, unless I request to server with a PUT.

rakesh:/test/libcoap/examples$ ./coap-client -m get -T cafe coap://[::1]/dynamic/url/123
4.04 Not Found
rakesh:/test/libcoap/examples$ ./coap-client -m put -T cafe coap://[::1]/dynamic/url/123
rakesh:/test/libcoap/examples$ ./coap-client -m get -T cafe coap://[::1]/dynamic/url/123
rakesh:/test/libcoap/examples$

is this expected?

[mrdeep1]

If you are running the coap-server with the -d option, then the answer is yes.

It is allowing PUT to an unknown resource, which then creates the resource so allowing for a subsequent GET.

[rakeshksahu]

thanks, closing this issue.