Updated 'dict' handling for responses without a body to use an empty dictionary #171
Conversation
…dictionary Signed-off-by: Mike Raineri <[email protected]>
|
@z46-dev you may want to try this out yourself; it seems to work well on some of the responses I've tried with no response bodies. |
|
So I did some more digging last night, apparently this gets loaded into the text field, not a blank string. I'm not sure if this is a violation of the redfish spec on Intel's part, but it seems that this internal server error is a generic response. |
|
Ah... crud... That's definitely breaking the spec... |
|
@z46-dev so, some good news. We chatted about this a bit and we came to the rationale that there may be cases where a service simply cannot return a proper Redfish error response for all HTTP 500 cases, even though the spec requires it. Depending on the service's design, the overall web server may be croaking and simply have no context about the request even being a Redfish request (resulting in a stock error page from the web server). So, I'll make the following change on top of what's already here. Specifically for 500 status codes, if the response does not unpack from JSON properly, return an empty dictionary rather than throwing an exception. However, for all other status codes, we still want to throw an exception since the service should be in a good enough state to know that it's servicing a Redfish request (and thus adhere to the Redfish error response requirements). |
|
@mraineri That's pretty good, thank you. I think that's a good resolution, since it doesn't need to change the spec, but does allow for handling of errors with the server you're requesting too. Thank you for your help! |
Signed-off-by: Mike Raineri <[email protected]>
|
@z46-dev I just pushed updates to this branch to support this corner case. Would you be able to test it on your end? |
Fix #170