-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Description
I would like to build a resource with multiple content types, for example, a CBOR and a JSON representation. For this support for the CoAP Accept option would be required.
I have no problems with implementing this option, but for now I have a few ways about how to implement this:
- Let the handlers do the check. This would require support with every handler for the option. The handler functions implement the check and return a 406 when an invalid content type is specified. This does not require any change in the
coap_resource_tstruct, but does allow for violating the CoAP RFC if the handler does not check the Accept header. - Do a check after the handler is finished if the Content-Type header matches the Accept type. This way the handler can implement support, but it is not required to actively support it. The downside of this is that responses are generated while they are useless because the client requested the wrong content type.
- Add a field (content_type array) to the
coap_resource_tstruct with the supported content types. This way thecoap_handle_reqfunction can implement a header check and the handler can implement a switch to support multiple types. Some additional checking could be done to ensure that the content type returned by the handler is truly the requested content type. An additional benefit of this is that the .well-known/core can also supply content-type info. The downside of this is of course that the handler API changes.
I'd like to have some opinions on this. I'm willing to implement this myself, but I'd rather not build an implementation that is rejected.
Metadata
Metadata
Assignees
Labels
No labels