Q-Block support detection fails in some cases about libcoap HOT 5 CLOSED

The first and the most obvious problem occurs when the server does not have a root resource configured.

Agreed that / does not have to be there. Will update this to .well-known/core which should always be there.

The second issue is that even when the server does support Q-Block it will not necessarily return Q-Block2 option in the response.

That should be fine - I will check things later. However, as Q-Block1 is set to be Critical, a Server that does not recognize or support Q-Block1 MUST send back a 4.02 as per RFC7252 5.4.1 Critical/Elective so server support should be properly detected.

Unrecognized options of class "critical" that occur in a
Confirmable request MUST cause the return of a 4.02 (Bad Option)
response.  This response SHOULD include a diagnostic payload
describing the unrecognized option(s) (see [Section 5.5.2]). 

from libcoap.

If a server supports Q-Block, but does not have the / resource, the client will not detect Q-Block support as there will be a 4.04 response. Code will be updated to use /.well-known/core instead which should always be there and can be used for testing Q-Block support.

When testing for Q-Block support, the client uses the Q-Block2 option configured as block 0, block size 16 bytes, with the More bit unset to indicate that it is asking for for block 0 only (not the entire payload). Note that this is different to the Block2 option. It is very unlikely that the /.well-known/core response will be 16 or less bytes, so the server will be forced to respond using Q-Block2 (assuming supported) which the client then detects. So this part of the code is working as expected.

If a server receives a Q-Block option that it does not support (when using CON), as it is a critical option, it MUST respond with a 4.02 (RFC7252 5.4.1. Critical/Elective.) There are however CoAP servers that subscribe to "be tolerant of issues" and ignore options they do not understand/support. But here, they are not responding with a Q-Block2, so it is safe to assume they do not support Q-Block.

It is possible to add in a session only setting of a flag to indicate that the server supports Q-Block no matter what. However if a server does not support Q-Block (and silently ignores it) certainly usage of Q-Block1 by the client will not work as expected. Is this flexibility actually required?

from libcoap.

It is possible to add in a session only setting of a flag to indicate that the server supports Q-Block no matter what. However if a server does not support Q-Block (and silently ignores it) certainly usage of Q-Block1 by the client will not work as expected. Is this flexibility actually required?

I was looking for this possibility mostly as a way to sidestep the issue with the automatic detection. If the latter works reliably I guess there is no real need for manual override. Skipping the detection might save some time on the client side, but I doubt that it will be of much importance in practice.

from libcoap.

I was looking for this possibility mostly as a way to sidestep the issue with the automatic detection.

Make sense. #1372 has now been merged. Can this issue be closed now?

from libcoap.

As far as I am concerned, yes.

from libcoap.