tree 18566623da4ff47c7ef12bb73d2b91fbf64cc73c
parent b9e1522807ac9411a03f0d37b07ac35f4cebbe3c
author Ed Tanous <edtanous@google.com> 1655940000 -0700
committer Ed Tanous <ed@tanous.net> 1657237821 +0000

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