-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conflict Write(Update)/Execute again ? #527
Comments
Thanks for spotting this issue. We will clarify the sentence in the v1.2.1 bugfix release. |
I'm not sure I was clear but the real issue for me is more that a POST on
Meaning that implementation need to know the model to understand it. |
When receiving a POST on /{Object ID}/{Object Instance ID}/{Resource ID}, the algorithm is:
So yes the implementation needs to know the list of allowed operations, and the multiplicity or not of the targeted resource. But this information is present in the implementation anyway. Another possibility: the format of the payload can be used to determine if the POST is an Execute or a Write (Partial Update) operation:
|
My point is that was not considered as a such good idea by the past : #29 (comment)
This can do the tricks, thanks for sharing the idea 🙏 |
Group agrees that this issue is resolved and can be closed 10/31/2023 |
Answering to #526, I just see that at least since LWM2M 1.2 (transport§6-4-4-Device-Management-and-Service-Enablement-Interface) POST on
/{Object ID}/{Object Instance ID}/{Resource ID}
have several meaning.So, a client must know the model to be able to interpret it.
I'm not totally sure if allowing POST for partial write on resource was done on purpose because the spec is a bit contradictory :
It seems to alllow it here :
/{Object ID}/{Object Instance ID}/{Resource ID}
/{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID}
/{Object ID}/{Object Instance ID}/{Resource ID} only for Multiple-Instance Resources
but not there :
(meaning POST is only for Object Instance)
A similar problem was raised several years ago(see #29). It was considered as an issue and fixed.
This new addition reintroduce this kind of problem.
The text was updated successfully, but these errors were encountered: