[CONTROLLER-520] Invoking an RPC with no expend input should not fail when content type is set to application/json Created: 29/May/14  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: controller
Component/s: restconf
Affects Version/s: Helium
Fix Version/s: None

Type: Bug
Reporter: Devin Avery Assignee: Devin Avery
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: PC


External issue ID: 1100

 Description   

When I invoke an RPC which expects no input, it shouldn't matter what the content/type header is set to. Unfortunately you MUST have a content type other than application/json (or xml, or their variants) in order to get the call routed to the correct REST method. This happens because the code that deserializes the string into a composite node asserts that there be something defined.

Instead of enforcing content at the deserialization (which is not aware of whether input is required or not) we should allow deserialization to return null, and perform the proper validation when have the RPC call definition.



 Comments   
Comment by Devin Avery [ 04/Sep/14 ]

Did not end up having time to get to this. If we can fix before release great, otherwise it should move off to lithium

Comment by Tom Pantelis [ 10/Sep/14 ]

Tried to reproduce (with cancel-toast which takes no inout) but it works properly no matter what the content type is. This was fixed upstream as the front-end parsing code now returns null if no input is provided and the proper checking is done in the service methods.

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