| commit | 89f180089bce9cc431d0b1053410f262f157b987 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Thu Mar 24 18:38:24 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Thu May 05 20:42:42 2022 +0000 |
| tree | be11f5c9e43112a921a1c037d8f065396adcb687 | |
| parent | 031514fb7798057bbe0261a92b6c368cd5a35f66 [diff] |
Implement etag headers This commit implements a limited support for the production of etags on json resources. It is intended to cause two things: 1. To get bmcweb to pass the PROTO_ETAG_ON_GET_ACCOUNT check, as well as the redfish spec, which states: "Implementations shall support the return of ETag headers for GET requests of ManagerAccount resources." 2. Begin discussions on what client-facing caching could look like in the future, and to implement the fewest lines of code this author could think of, with the hope of extending it later. As written, it injects into the Response class a method that, for json responses, uses std::hash<json> to generate an etag. This was chosen under the assumption that it caused the least binary impact, and is already a function provided by nlohmann, so required minimal implementation effort to get something that functioned to the standard: https://json.nlohmann.me/api/basic_json/std_hash/#version-history I'm open to discussions if this should be improved in the future to include more entropy, or to be a "weak" etag, but I think starting with std::hash is a good first step. This patchset intentionally does notimplement handling of the If-None-Match, or If-Match headers that a caching client would likely send that implements this. That is not explicitly required by the spec, relatively complex, and probably has consequences that this author doesn't want to write the test cases for (yet). This lack of support makes this patchset largely only "useful" in passing the tests, and implementing the spec to the letter, it does not generalize a caching client feature that improves performance. Tested: curl -vvvv --insecure --user root:0penBmc https://192.168.7.2/redfish/v1 Contains in the response: ETag: "765E4548" The redfish protocol validator now passes the PROTO_ETAG_ON_GET_ACCOUNT test, which increases our passing test count by 4 compared to previously. Current counts are 352 passing, 30 failing, 36 not tested. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I3389b2ba98bf1276e1cb2d9c5954437b924f2d94
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja -C builddir test ninja -C builddir coverage
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.