Set UnknownProperty message to be an error
This normally wouldn't be so big of a deal, but the redfish-protocol
validator tests this case in the REQ_PATCH_BAD_PROP test.
From the specification:
'''
If all properties in the update request are read-only, unknown, or
unsupported, but the resource can be updated, the service shall return
the HTTP 400 Bad Request status code and an error response with messages
that show the non-updatable properties.
'''
We wrote our code almost right for handling this case, but we put the
response into the per-property responses instead of the error responses.
In terms of backward compatibility, technically this is changing the
behavior, but considering that it's behavior in an error case, most
implementations only look at response code, and this is moving to be
compliant with the specification, it doesn't seem like there would be
any reason to provide both the old message and the new one, and this has
a low to zero likelihood of any actual impact. To hit this condition,
clients would have to be ignoring the error code response AND using a
property that's unknown to the BMC. Clients that make both mistakes
seems unlikely.
Tested:
Code now passes the REQ_PATCH_BAD_PROP test. 10 failing test cases down
to 8.
'''
curl -vvvv --insecure --user root:0penBmc https://192.168.7.2/redfish/v1/AccountService/ -X PATCH -d '{"foo": "bar"}'
'''
Returns an object with an "error" key in it.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I8a19ed2bcfc91765b63d4544877332038e171c02
diff --git a/redfish-core/src/error_messages.cpp b/redfish-core/src/error_messages.cpp
index 2254195..c688fdc 100644
--- a/redfish-core/src/error_messages.cpp
+++ b/redfish-core/src/error_messages.cpp
@@ -1289,7 +1289,7 @@
void propertyUnknown(crow::Response& res, std::string_view arg1)
{
res.result(boost::beast::http::status::bad_request);
- addMessageToJson(res.jsonValue, propertyUnknown(arg1), arg1);
+ addMessageToErrorJson(res.jsonValue, propertyUnknown(arg1));
}
/**