Skip to content

nanocoap: CoAP Accept option implementation #23

@bergzand

Description

@bergzand

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:

  1. 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_t struct, but does allow for violating the CoAP RFC if the handler does not check the Accept header.
  2. 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.
  3. Add a field (content_type array) to the coap_resource_t struct with the supported content types. This way the coap_handle_req function 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

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions