Hi folks, It looks to me like at least some of the sample server code mis-handles POST requests. Specifically
resource/csdk/stack/samples/linux/SimpleClientServer/ocserver.cpp android/examples/simpleserver/src/main/java/org/iotivity/base/examples/Light.java In both cases the code handling POST requests simply creates a new resource with a new URI. I think this violates the CRUDN to CoAP mapping on pages 98 and 99 of the OIC Core Spec v. 1.0.0, which states clearly that the target URI in a POST request must exist. If it does not, a "Resource not found" response "shall be returned". This is how I interpret the mapping: ;; CRUDN to CoAP mapping: both CREATE and UPDATE may map to either ;; POST or PUT, depending on whether the target URI already exists ;; on the server and on the payload of the request: ;; POST with existing URI, with complete resource rep in payload ;; -> CREATE new resource with new (server-generated) URI ;; POST with existing URI, with partial resource rep in payload ;; -> UPDATE (i.e. MODIFY) existing resource ;; POST with new URI -> "Resource not found" error ;; PUT with new URI -> CREATE new resource with given URI ;; PUT with existing URI -> UPDATE - i.e. REPLACE entire existing resource ;; In summary, PUT means create or replace, POST means create or modify So the first thing to be done in both cases is to check and see if the URI already exists, but it doesn't look like either of those to samples do this. More fundamentally, why isn't this logic implemented by the Iotivity kernel stack? It seems to me that the CoAP methods should be completely handled by the stack and never exposed at the application layer. The client code should only have to deal with OIC CRUDN operations. In other words the incoming request types should be RETRIEVE instead of GET, CREATE instead of PUT/POST, etc. Otherwise I don't see how the Iotivity stack by itself could conform to the OIC protocol specification. Thanks, Gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160623/1041374f/attachment.html>
