[NETCONF-15] PUT method returns wrong status code when new resource is created Created: 15/Jan/15  Updated: 15/Mar/19  Resolved: 10/Aug/16

Status: Resolved
Project: netconf
Component/s: restconf-nb
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Andrej Marcinek Assignee: Jakub Toth
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Other

Issue Links:
Blocks
blocks TOPOPROCES-86 topoprocessing CSIT tests failing due... Resolved
External issue ID: 2594

 Description   

When creating new resource with PUT method, status code 200 OK is returned.
But RESTCONF Protocol draft-bierman-netconf-restconf-04 says:
Consistent with [RFC2616], if the PUT method creates a new resource,
a "201 Created" Status-Line is returned. If an existing resource is
modified, either "200 OK" or "204 No Content" are returned.

 Comments   
Comment by Vaclav Demcak [ 24/Apr/15 ]

I guess, there is some mispoint for target specifications so:

draft-bierman-netconf-restconf-02 is a targeted implementation specification for now and it doesn't say anything about PUT create vs update.
new target implementation specification is draft-ietf-netconf-restconf-04 (see NETCONF-18) and it realy says:

"Consistent with [RFC 7231], if the PUT request creates a new resource,
a "201 Created" status-line is returned. If an existing resource is
modified, either "200 OK" or "204 No Content" are returned."

so here is patch for fix:

https://git.opendaylight.org/gerrit/#/c/19009/

Comment by Vratko Polak [ 10/Sep/15 ]

Current Target Milestone is set to Lithium-1. Is this bug planned to be fixed in Lithium-SR2?

Comment by Robert Varga [ 13/Nov/15 ]

Move to NETCONF project

Comment by Tomas Cere [ 24/Nov/15 ]

Needs to be ported to Netconf repo

Comment by Tomas Cere [ 21/Dec/15 ]

Port of li patch:
https://git.opendaylight.org/gerrit/31693

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.

Comment by Vratko Polak [ 21/Dec/15 ]

> Port of li patch

Li patch is also waiting for review: https://git.opendaylight.org/gerrit/21183

Comment by Vratko Polak [ 21/Dec/15 ]

The fix may affect multiple system test suites in integration/test project.
A warning e-mail has been sent https://lists.opendaylight.org/pipermail/integration-dev/2015-December/005434.html
but perhaps weather event will be even more consumer-friendly.

Comment by Jakub Toth [ 14/Jun/16 ]

https://git.opendaylight.org/gerrit/#/c/40235/

Comment by Robert Varga [ 17/Jun/16 ]

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.

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).

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.

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.

Comment by Jakub Toth [ 07/Jul/16 ]

https://git.opendaylight.org/gerrit/#/c/40235/

Generated at Wed Feb 07 20:13:57 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.