Comments (5)
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.
Related Issues (20)
- Request token is unexpectedly replaced with nonsense HOT 15
- [Non-conformance] Handling CoAP Invalid Versions HOT 2
- No callback if DTLS connection with OpenSSL server and client fails due to PSK mismatch HOT 3
- Add coap_get_resource_from_uri_path() to man pages. HOT 2
- HTTP/S Support for Proxy URIs in CoAP to HTTP Proxy HOT 4
- [Non-conformance] Handling Unreapeatable Options HOT 1
- Incorrect header passed to response_handler after finishing Replay Window scenario. HOT 7
- Actively denying a new session HOT 4
- Failing to set mtu when WOLFSSL_DTLS_MTU is enabled HOT 1
- Assertion !lock->in_callback failed in coap_lock_lock_func() during application shutdown HOT 10
- Build with wolfSSL not loading certificates on server side HOT 3
- Memory leak in LwIP function `coap_udp_recvs` HOT 1
- PDU use after free when sending an OSCORE message with OSCORE disabled at build time HOT 5
- coap-client binary PSK HOT 17
- [Question] Proxy-scheme and proxy-uri example with coap-client and coap-server applications HOT 6
- Make coap_print_wellknown customizable HOT 6
- Wrong
- Access Token option addition to libcoap HOT 1
- Clarification on cancelling a block-wise request in the middle of transaction at client's end HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libcoap.