-
Notifications
You must be signed in to change notification settings - Fork 424
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
Enable application control over .well-known/core response #1428
Conversation
fe0ba6f
to
eb1685b
Compare
I do not understand what the last documentation issue is about. |
You need to update the man page checker with
Then run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this work. Some changes are needed.
@anyc it would be good to get the code updated, squashed into 1 commit ready to be merged so it can be added into 4.3.5rc1 which will be happening shortly. This is needed for any reverse proxy to pass on .well-known/core. |
Ah, I thought it would be easier to review if I split it into smaller commits. I pushed a new commit where only the coap_handler issue remains unsolved. |
But it seems it does not work anymore with the new locking changes:
|
Maybe this helps:
|
Looking at why locking is currently failing with your code. |
I can see the issue. hnd_get_wellknown() is being treated as an application handler, not as an internal libcoap handler. Thinking through how best to handle this as context does need to be locked (for multi-thread safety) as context->resources is getting iterated through in coap_print_wellknown_lkd(). |
Try this fix |
Seems to work, thank you. I also added the request object as an additional parameter to the callback signature as I need this if I am going to use async functions. |
Looks good - thanks for getting this together. |
As described in #1425, this PR makes it possible for the application to control what is returned for .well-known/core requests.