| commit | 3e082749f3301116de14ac61661a625897a75971 | [log] [tgz] |
|---|---|---|
| author | Asmitha Karunanithi <asmitk01@in.ibm.com> | Tue Nov 24 12:41:42 2020 +0530 |
| committer | Asmitha Karunanithi <asmitk01@in.ibm.com> | Tue Nov 24 12:41:42 2020 +0530 |
| tree | b6631767056cb4865ffa177c5cffe412adb34d5f | |
| parent | a8fe54f09be1deefc119d8dcf100da922496d46d [diff] |
Pointing to the latest Message schema in JSON error response
The odata.type of the message, included in the error response JSON
is changed to point to the latest one (Message.v1_1_1) as there was
conflict in the code, where it points to v1_0_0 schema and a property
- MessageSeverity has been used (introduced in v1_1_0)
Tested By:
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The request failed due to an internal service error. The service is still operational.",
.
.
.
}
],
"code": "Base.1.4.0.InternalError",
"message": "The request failed due to an internal service error. The service is still operational."
}
}
Signed-off-by: Asmitha Karunanithi <asmitk01@in.ibm.com>
Change-Id: I57546adaffc2370c0314a2c2184799c387ec7272
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 -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.