The primary reason looks to be more with the happy path in mind with HTTP status codes and ensure the response body is JSON-formatted. So, in the typical case where there is a response body, you want an assurance that the data is decoded into a dictionary.

However, I can see the need to harden the library a bit in this regard. There will be cases where no response body is valid.

To be clear, is your situation the service is returning a 500 with no response body, or 500 with a non-JSON response? If the latter, that should be taken back to Intel as a spec violation. All responses in the 4XX and 5XX range (if there is a body) are expected to follow the "Error responses" clause of the Redfish Spec.

The response is a 500 with no body. Thank you for your quick response!

Okay, that's good news.

I'd like to propose adding a check prior to that try/except block. If the response length is 0, return None. That will preserve existing behavior to throw an exception when an invalid payload format is returned.

Thank you, that sounds like a good solution. I think the ability to handle status codes ourselves is good too. Thank you very much!

One other consideration; could an empty dictionary be acceptable over None? I'm thinking an empty dictionary might be more compatible with others consuming the library.

That's a good question. I'm not sure how others would try to parse the response. Obviously junk data can't be provided, but an empty dict could let someone continue parsing rather than stopping when seeing None. But None also means changing the return data types which is a "semi-breaking" change. Either works for me, and it should be fine provided users query the status code first. The issue with that is we don't know if people will actively check the status code.

Thanks for your input; I'll ask around to see what's preferred.

FWIW, when I write scripts using this library, I do check the status code before accessing dictionary members. The code I'm leveraging to pull out error messages (when I get back a 4XX or 5XX) does appear to gracefully handle these cases already and should continue to work after this change (regardless of returning None or an empty dictionary).

Awesome, thank you very much. I appreciate the support!