summaryrefslogtreecommitdiff
path: root/http/http_connection.hpp
diff options
context:
space:
mode:
authorEd Tanous <edtanous@google.com>2023-02-07 21:02:07 +0300
committerEd Tanous <ed@tanous.net>2023-03-14 22:00:34 +0300
commitad595fa64f619124eadcdfc2af259a1975136399 (patch)
treeda02f9b36676a5e389985ae0dc8c95e0642965d6 /http/http_connection.hpp
parent5315c1b149b724d0395f42ca75d4660aaecdf351 (diff)
downloadbmcweb-ad595fa64f619124eadcdfc2af259a1975136399.tar.xz
Only parse to the depth requested
There are cases in aggregation where an expand parameter might get forwarded to a client. Because our previous expand algorithm assumed that any endpoint within bmcweb would only produce "depth=1" responses, it was reasonable to assume that the pre-response could not contain expanded content. Aggregated resources can't make that assumption. This commit attempts to pass through depth through the request, to ensure that we only expand the level that the user requested, and not any level returned by the request. This is done by using the existence of the resource identifer "@odata.id" to indicate each level in an expanded response. This should be fine since the Redfish spec requires that property to exist. Added unit tests to cover aggregation scenarios. Modified existing $expand tests to comply with the resource identifier dependency. Tested: New unit tests pass Queried '/redfish/v1/Systems?$expand=.($levels=2)' on an aggregated system whose satellite BMC supported $expand. The overall response was correctly expanded for both resources on the aggregating BMC as well as on the satellite BMC. Expanding the satellite resources did not require sending multiple queries to the satellite. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I20ba60ee39bac11ffb3fe1768cec6299cf9ee13e Signed-off-by: Carson Labrado <clabrado@google.com>
Diffstat (limited to 'http/http_connection.hpp')
0 files changed, 0 insertions, 0 deletions