[riot-notifications] [RIOT-OS/RIOT] nanocoap: Allow accessing opaque and other written options (#11437)

chrysn notifications at github.com
Wed Apr 24 16:12:34 CEST 2019

### Contribution description

This is an extension to the API of nanocoap that previously did not give the user a means to iterate over all options, or to look into option that do not fit one of the supported forms (extracting numbers or building a single-character-separated string).

The added function can be used to plainly read option values (eg. in evaluating the ETag options of a request), but also to update options previously written (eg. to set an already allocated ETag, or to find which bit to change when setting the "more" flag on a Block2 response after having built the output). It can also be useful when iterating over all options of a message, eg. to build a cache key or when implementing OSCORE.

No method of iteration is provided per se; it is expected that users of that API will reach into `.options_len` / `.options` to obtain the count of options and their stored optionnumber. (That would almost have been sufficient to do what this function offers, but the options values lack the information on where the option actually starts, which is usually obtained by the internal `_parse_option`).

### Testing procedure

The second commit adds a resource to the nanocoap_cli test. In that test, a GET to the /req-opts resource now gives output similar to:

$ aiocoap-client "coap://[fe80::acfc:4bff:fe32:4907%tap0]/req-opts?foo=bar"
11: 7265712d6f707473
15: 666f6f3d626172

### Issues/PRs references, impact & status

This has not been discussed in a previous issue/PR, but can be seen as the reading counterpart of https://github.com/RIOT-OS/RIOT/pull/11386 -- in combination, one can reproduce arbitrary options from the request message into the response message (eg. the Echo option).

This change has no impact on the output code of existing programs as it purely adds a method. It increases the API surface of nanocoap, and introduces a concept there that was previously not used much (the index into `pkt->options`) -- it's more common in the internal API to pass around pointers to the start of the option right away.

The change is working as it is, but I'm open to suggestions on how the same goal can be achieved more within the style of nanocoap, eg. by not requiring the user to access the pkt struct fields.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * nanocoap: Allow access to arbitrary options
  * nanocoap: Add test for coap_opt_by_index

-- File Changes --

    M sys/include/net/nanocoap.h (21)
    M sys/net/application_layer/nanocoap/nanocoap.c (15)
    M tests/nanocoap_cli/README.md (3)
    M tests/nanocoap_cli/request_handlers.c (34)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190424/2eefab36/attachment.html>

More information about the notifications mailing list