nanocoap: incomplete response to /.well-known/core request

[kb2ma]

Description

nanocoap client does not receive a complete response when send blockwise, for example a response from a nanocoap server for /.well-known/core.

A gcoap client experiences the same problem, but this report focuses on nanocoap.

Steps to reproduce the issue

A nanocoap server's /.well-known/core resource uses the CoAP block extension to return the resource over multiple responses. Use nanocoap_get() or nanocoap_receive() to retrieve it. See an example when using the nanocoap client CLI in #10640.

Expected results

Since nanocoap_(get|receive) do not understand the block2 option in the response, they should respond with some error code (negative value) to the caller.

Actual results

nanocoap_(get|receive) responds with the length of response from the server.

Versions

Error occurs with a request to nanocoap /.well-known/core since 2018.10 release, which started to use a block-based response.

[kaspar030]

@bergzand Maybe take a look?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

Ping @bergzand (and maybe @chrysn and @cgundogan)?

[chrysn]

The block options, when not supported by a library, should not need special treatment in the sense that any other critical option would need such a treatment as well.

A client application needs to handle any critical option that comes along. So we could check the options and hand an error to the client if any critical option is present. Or we require that the client check all critical options and abort on its own if it finds one unprocessable (as we implicitly do now, in my understanding). Or we allow the client to pass a set of options to the library which it promises to look into, and present an error if one is present that's not on the list.

I think we can (and should) do something about this, but it'll need some discussion, and it'd equally apply both to direct nanocoap applications and Gcoap (even though there may be options which Gcoap takes care of, and nanocoap won't).