Closed anyc closed 4 weeks ago
As a reverse proxy, are you forwarding all requests on to the internal server, or only those that have access based on DTLS identity?
If all, then .well-known/core needs to be passed on as well which would need a code change.
Otherwise, the principle of having a app controllable list of what is returned as a response to .well-known/core makes sense to me.
In my case, I only forward requests that start with a configurable URI prefix. I opened a corresponding PR.
Thanks for merging the PR.
Now that coap_print_wellknown()
is a part of the Public API, and with #1431 providing support for passing .well-known/core
to the unknown resource created by coap_resource_unknown_init2()
with the GET handler defined, is there any need for the complication of coap_register_print_wellknown_callback()
?
It is also possible for the server app to create a resource for .well-known/core
with an appropriate GET handler. In this case, with #1431, coap_print_wellknown()
does not include .well-known/core
in its list.
coap_method_t
does not include coap_print_status_t
's buf
, buflen
or offset
. context
is obtained from coap_session_get_context(session)
.
The GET handler would just need to follow the principles behind hnd_get_wellknown()
(without the locking).
Thooughts?
Sounds good to me. I will give it a try.
coap_register_print_wellknown_callback()
reverted out as all works with the unknown resource handler.
Hello,
on my device, the CoAP server uses the async functions to act as a reverse proxy for another internal server process with different privileges. I would like to provide the list of resources of the internal server with the list of resources of the main server so a client does not see a difference. To achieve this, I think it would be necessary to register a user callback function which is called instead of the coap_print_wellknown() function and this callback could in turn call coap_print_wellknown() which would have to be made public for this. My callback would then add the URIs from the internal server to the list that libcoap provides.
I could query the internal server during startup and create dummy resources which then would automatically show up but I would prefer to query the internal server on demand only. I think this could also be handy in other cases when coap_resource_unknown_init2() is used to answer requests dynamically.
Another use case for me is that my server grants access to resources based on the DTLS identity and we would like to be able to hide certain resources from users with low privileges. As we store privilege information as part of the session userdata, the session would also have to be passed to the coap_print_wellknown callback.
As far as I understand the corresponding libcoap code, this should be possible with only a few changes. Would you accept such a pull request in principle?
Thank you!