tree a3b9291f037b5b5aa4367bacd1ddb9f2034b1eb1
parent 7de9f811db3400121e1453b1fa3da09ae6df69f6
author Ed Tanous <edtanous@google.com> 1631563652 -0700
committer Ed Tanous <ed@tanous.net> 1631896783 +0000

Nullify HttpHeaders per the specification

Per the definition of HttpHeaders in the schema "This object shall be
null or an empty array in responses."  This commit does as the
specification commands.

In theory, this could break clients that were checking the HttpHeaders
after posting it, but it's not being put behind an option flag in this
patchset for a couple reasons:
1. This has the potential to leak security secrets, as the normal use
case for this is to put in Authorization headers.
2. Given that the most likely client that would "break" is the one doing
the POST to this API, and it already has the data, it seems unlikely
that there's any implementation that would explicitly check that the
returned object is identical to the sent one, especially if error codes
are handled properly.

Tested:
curl -vvvv --insecure -u root:0penBmc "https://192.168.7.2:443/redfish/v1/EventService/Subscriptions" -X POST -d "{\"Destination\":\"http://192.168.7.2/foo\",\"Context\":\"Public\",\"Protocol\":\"Redfish\",\"HttpHeaders\": [{\"Foo\": \"Bar\"}]}"
Succeeded with 200

curl -vvvv --insecure -u root:0penBmc "https://192.168.7.2/redfish/v1/EventService/Subscriptions/405645225"
Returned

"HttpHeaders": [],

As part of its object

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I32181044d0af6b4395daea3f6ca4480022fc7553