| commit | 0242baffb0c05ea448d8bde0c09950d069a272a7 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <ed@tanous.net> | Thu May 16 19:52:47 2024 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Tue May 28 18:03:10 2024 +0000 |
| tree | ba05e048a47e0b9f6c8af824f0c77f10d950b49f | |
| parent | 090ab8e1042e14f7e5e02572ae2a2102677f1f00 [diff] |
Implement Chunking for unix sockets Response::openFd was added recently to allow handlers to pass in a file descriptor to be used to read. This worked great for files, but had some trouble with unix sockets. First, unix sockets have no known length that we can get. They are fed by another client until that client decides to stop sending data and sends an EOF. HTTP in general needs to set the Content-Length header before starting a reply, so the previous code just passes an error back. HTTP has a concept of HTTP chunking, where a payload might not have a known size, but can still be downloaded in chunks. Beast has handling for this that we can enable that just deals with this at the protocol layer silently. This patch enables that. In addition, a unix socket very likely might not have data and will block on the read call. Blocking in an async reactor is bad, and especially bad when you don't know how large a payload is to be expected, so it's possible those bytes will never come. This commit sets all FDs into O_NONBLOCK[1] mode when they're sent to a response, then handles the subsequent EWOULDBLOCK and EAGAIN messages when beast propagates them to the http connection class. When these messages are received, the doWrite loop is simply re-executed directly, attempting to read from the socket again. For "slow" unix sockets, this very likely results in some wasted cycles where we read 0 bytes from the socket, so shouldn't be used for eventing purposes, given that bmcweb is essentially in a spin loop while waiting for data, but given that this is generally used for handling chunking of large payloads being generated, and while spinning, other reactor operations can still progress, this seems like a reasonable compromise. [1] https://www.gnu.org/software/libc/manual/html_node/Open_002dtime-Flags.html Tested: The next patch in this series includes an example of explicitly adding a unix socket as a response target, using the CredentialsPipe that bmcweb already has. When this handler is present, curl shows the response data, including the newlines (when dumped to a file) ``` curl -vvvv -k --user "root:0penBmc" https://192.168.7.2/testpipe -o output.txt ``` Loading the webui works as expected, logging in produces the overview page as expected, and network console shows no failed requests. Redfish service validator passes. Change-Id: I8bd8586ae138f5b55033b78df95c798aa1d014db Signed-off-by: Ed Tanous <ed@tanous.net>
This component attempts to be a "do everything" embedded webserver for OpenBMC.
The webserver implements a few distinct interfaces:
bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.
Bmcweb supports multiple authentication protocols:
Each of these types of authentication is able to be enabled or disabled both via runtime policy changes (through the relevant Redfish APIs) or via configure time options. All authentication mechanisms supporting username/password are routed to libpam, to allow for customization in authentication implementations.
All authorization in bmcweb is determined at routing time, and per route, and conform to the Redfish PrivilegeRegistry.
*Note: Non-Redfish functions are mapped to the closest equivalent Redfish privilege level.
bmcweb is configured per the meson build files. Available options are documented in meson_options.txt
meson setup builddir ninja -C builddir
If any of the dependencies are not found on the host system during configuration, meson will automatically download them via its wrap dependencies mentioned in bmcweb/subprojects.
bmcweb relies on some on-system data for storage of persistent data that is internal to the process. Details on the exact data stored and when it is read/written can seen from the persistent_data namespace.
When SSL support is enabled and a usable certificate is not found, bmcweb will generate a self-signed a certificate before launching the server. Please see the bmcweb source code for details on the parameters this certificate is built with.
bmcweb is capable of aggregating resources from satellite BMCs. Refer to AGGREGATION.md for more information on how to enable and use this feature.