commit | d32c4fa936f9a88fc1dd124201ed11a6a90a18c5 | [log] [tgz] |
---|---|---|
author | Ed Tanous <edtanous@google.com> | Tue Sep 14 13:16:51 2021 -0700 |
committer | Ed Tanous <edtanous@google.com> | Tue Oct 05 10:51:01 2021 -0700 |
tree | fad1030fb5244223fa81ae84b0e4cea8b0bdbd44 | |
parent | b7ff344535c42af074c60bfb272ef66a2ba157b4 [diff] |
Boost uri update Update to the latest version of boost::uri The newest version of boost uri makes some breaking changes that we need to account for. At the same time, we take the opportunity to move to the error code based parse methods that don't rely on exceptions. The biggest changes are: The standalone build is no longer present. A discussion with the boost::url maintainers shows that our best option is to do a simple copy of the headers, and compile boost/url/src.hpp in a separate file. This is intended to allow people to pull the library in "standalone" and not have to rely on the build machinery in boost-url, which we don't really need. Interestingly, this file doesn't have a newline at the end, which clang correctly flags. OpenBMC doesn't really need that warning, as we rely on clang-format to do that, so we add -Wno-newline-eof clang to get the code to compile there. All url parsers are moved to the parse_uri, or parse_relative_uri equivalents. This slightly tightens the requirements around what URLs are accepted, but in no ways that should break anything. (Ie, "/redfish/v1" is no longer accepted for a virtual media endpoint. boost::urls::url_view::params_type has been renamed to query_params_type, and the relevant methods have been updated. Because of the missing standalone mode, we now need to use boost::string_view which doesn't implicitly construct from std::string_view. Some discussion on the boost list shows that this is coming soon, so that cruft can eventually be cleaned up, but for now we need the construction. Tested: Loaded in qemu, and ran some URLs (/redfish/v1 and /redfish/v1/Chassis) to ensure that the url handler functions as intended. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I5843776d4ec01b4d92af2ee3a9cf1ebb1d920ae7
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 coverage -C builddir test
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.