https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-15 netconf <p>When creating new resource with PUT method, status code 200 OK is returned.<br/> But RESTCONF Protocol draft-bierman-netconf-restconf-04 says:<br/> Consistent with <span class="error">&#91;RFC2616&#93;</span>, if the PUT method creates a new resource,<br/> a "201 Created" Status-Line is returned. If an existing resource is<br/> modified, either "200 OK" or "204 No Content" are returned.</p> <p>Operating System: Linux<br/> Platform: Other</p> NETCONF-15

PUT method returns wrong status code when new resource is created

Bug Resolved Done Jakub Toth Andrej Marcinek Thu, 15 Jan 2015 09:26:08 +0000 Fri, 15 Mar 2019 22:22:10 +0000 Wed, 10 Aug 2016 08:27:31 +0000 restconf-nb 0 9 <p>I guess, there is some mispoint for target specifications so:</p> <p>draft-bierman-netconf-restconf-02 is a targeted implementation specification for now and it doesn't say anything about PUT create vs update.<br/> new target implementation specification is draft-ietf-netconf-restconf-04 (see <a href="https://jira.opendaylight.org/browse/NETCONF-18" title="Enhance RESTconf to implement latest draft-ietf-restconf-netconf" class="issue-link" data-issue-key="NETCONF-18"><del>NETCONF-18</del></a>) and it realy says:</p> <p>"Consistent with <span class="error">&#91;RFC 7231&#93;</span>, if the PUT request creates a new resource,<br/> a "201 Created" status-line is returned. If an existing resource is<br/> modified, either "200 OK" or "204 No Content" are returned."</p> <p>so here is patch for fix:</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/19009/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/19009/</a></p> <p>Current Target Milestone is set to Lithium-1. Is this bug planned to be fixed in Lithium-SR2?</p> <p>Move to NETCONF project</p> <p>Needs to be ported to Netconf repo</p> <p>Port of li patch:<br/> <a href="https://git.opendaylight.org/gerrit/31693" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/31693</a></p> <p>Discussion with Tony revealed that this way of handling it will introduce some performance issues, so we will probably have to find another way of handling this.</p> <p>&gt; Port of li patch</p> <p>Li patch is also waiting for review: <a href="https://git.opendaylight.org/gerrit/21183" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/21183</a></p> <p>The fix may affect multiple system test suites in integration/test project.<br/> A warning e-mail has been sent <a href="https://lists.opendaylight.org/pipermail/integration-dev/2015-December/005434.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/integration-dev/2015-December/005434.html</a><br/> but perhaps weather event will be even more consumer-friendly.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/40235/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/40235/</a></p> <p>An interim "fix" can be to open a read-write transaction, issue a read (which returns a future) and a put, submit the transaction (which returns a future). Then wait for both futures to complete and return appropriate return code.</p> <p>The problem is that this will not be reliable, as it will suffer from race conditions anyway: if two such operations are executed concurrently, both will return 201 (as that is the state observed in transaction's isolated view).</p> <p>In order to solve this we need support from the data store, specifically an option to report the DataTreeCandidate view of the transaction's effect in the future returned by submit(). The DataTreeCandidate has to be then examined to ascertain whether the target resource was created or not.</p> <p>This will work for local modifications, transferring the candidate from a remote shard may prove to be too costly to be feasible. This definitely needs more analysis.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/40235/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/40235/</a></p> Blocks TOPOPROCES-86 Development External issue ID 2594 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01vxj: