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