BMC/OpenBmc/bmcweb.git/http, branch master

Refactor startAsyncWaitForSignal lambda

2026-09-24T06:43:40+00:00

Extract the long signal handler lambda in startAsyncWaitForSignal() into a named member function, afterWaitForSignal(), bound via std::bind_front(), per the <10 line lambda coding standard in docs/COMMON_ERRORS.md. Tested on AST2600 SoC: - `kill -HUP `, then `GET /redfish/v1/` Expected: cert reload, service stays active, 200 OK Actual: bmcweb.service remained active, GET returned HTTP 200 - `kill -TERM ` Expected: clean shutdown Actual: journalctl confirmed "bmcweb.service: Deactivated successfully" - RSV: 5845 Pass / 353 Warn / 0 Fail Change-Id: Id02f26fd680ae34639b521962b0f4e3d67c534bc Signed-off-by: Yuvakumar Selvamani

include,http: Extract getUserInfo/onRequestRecv

2026-09-19T14:52:07+00:00

Move long lambdas in getUserInfo() and onRequestRecv() into named functions, afterGetUserInfo() and afterCompleteRequest(), per the <10 line lambda rule in docs/COMMON_ERRORS.md. No functional change. Tested: - Tested on AST2600 SoC. - getUserInfo/afterGetUserInfo: sent an authenticated Basic-auth Redfish GET and confirmed a 200 response with no "Failed to populate user information" error in journalctl, proving populateUserInfo() succeeded via the extracted callback. - onRequestRecv/afterCompleteRequest: RSV's client uses HTTP/1.1, so it does not exercise this HTTP/2-only code path. Instead, used "curl --http2" and confirmed ALPN negotiated h2 and the request completed as HTTP/2 200. journalctl -u bmcweb confirmed both "onRequestRecv streamId:1" and the extracted callback's "res.completeRequestHandler called" fired for that stream. - Redfish Service Validator: 5830 Pass / 353 Warn / 0 Fail. Change-Id: I0e6365c682f6acc8d39510ad5f1fe239d747154f Signed-off-by: Yuvakumar Selvamani

http: Refactor handleMessage lambda

2026-09-11T15:46:11+00:00

Extract the long completion lambda in handleMessage() into a named member function, afterHandleMessage(), bound via std::bind_front(), per the <10 line lambda coding standard in docs/COMMON_ERRORS.md. Tested: - No functional change. - Build successfully compiled. - Redfish Service Validator passed with no new errors or warnings introduced. Change-Id: I54f4cbee152c04c2bd083e5fbbf6859b8277b887 Signed-off-by: Yuvakumar Selvamani

Prevent error level prints on disconnect of http2

2026-09-10T19:50:56+00:00

Previously, http2 disconnects that weren't cleanly stopped in openssl would result in a log message like: ''' [http2_connection.hpp:998] 0x2bba5e0 Error while reading: stream truncated ''' While it's valid to log that a client disconnected unclealy, clients seem to do this and clog up the logs. Tested: Redfish Service validator passes. I don't have a client that reproduces this; Inspection only. Change-Id: I9205500171912f7d82b31487b7df8d1a293d8c89 Signed-off-by: Ed Tanous

Add defensive callback invocation

2026-07-29T16:27:17+00:00

We have experienced a `std::bad_function_call` exception [1]. The journal entries are showing ``` Jun 17 15:27:21.985663 bmcwebd[1995]: [http_client.hpp:391] recvMessage() failed: asio.ssl error from https://10.5.10.140:17443/redfish/events Jun 17 15:27:22.043798 bmcwebd[1995]: [http_client.hpp:391] recvMessage() failed: stale parser from https://10.5.10.140:17443/redfish/events Jun 17 15:27:22.085644 bmcwebd[1995]: terminate called after throwing an instance of 'std::bad_function_call' Jun 17 15:27:22.086908 bmcwebd[1995]: what(): bad_function_call Jun 17 15:27:22.163520 systemd-coredump[4621]: Process 1995 (bmcwebd) of user 0 terminated abnormally with signal 6/ABRT ``` The matching line is ``` void recvMessage(const std::shared_ptr& /*self*/, const boost::system::error_code& ec, std::size_t bytesTransferred) { ... callback(parser->keep_alive(), connId, res); ... } ``` This would imply that the callback function pointer became null when it is invoked. ``` void sendNext(bool keepAlive, uint32_t connId) { ... conn->callback = nullptr; ... } ``` This may be happening due to the race condition between multiple async operations where the async call is waiting to be invoked but sendNext is executed first. This commit is to make the defensive checking of `callback` function pointer before invoking like ``` if (callback) { callback(parser->keep_alive(), connId, res); } ``` [1] https://en.cppreference.com/cpp/utility/functional/bad_function_call Change-Id: Ic23e17ea486433e3bb7493e8e3c1e56b1798c8e9 Signed-off-by: Myung Bae

Implement Response header count

2026-07-22T18:29:44+00:00

Add Response::headerCount() to return the total number of stored header fields on a response. The implementation counts the current header entries directly from the underlying Beast header container. Added unit coverage to verify the method reports the full header count after headers are added through the normal addHeader() path. Tested with: meson test -C build http_response_test --print-errorlogs This helper is used by response unit tests to verify that only the expected headers are present and that no unexpected headers are added to the response. See also: https://gerrit.openbmc.org/c/openbmc/bmcweb/+/91848 Change-Id: I28432bb4fc982db44cee0688395d04ac513d6749 Signed-off-by: Joel Pullokaran Jesin

Fix bug in asio resolver

2026-07-15T18:27:05+00:00

This regressed when the bypass was added. Fix the code for resolver=asio to properly construct the results object using the built in asio type instead of std::vector. Tested: Code compiles with resolver=asio again. Change-Id: I3d9ddc38b88a392cf82fc81bd5609f3360837393 Signed-off-by: Ed Tanous

Updating maxValues to support roughly 200 bmcweb sessions

2026-07-09T19:21:12+00:00

parseStringAsJson() routes through BmcwebSaxParse, which hard-caps a payload at 500 total JSON values to defend against malicious external HTTP request bodies. The most visible symptom is that bmcweb silently loses every persisted session across a restart once ~50 sessions accumulate (each persisted session is ~11 JSON values, so the file trips the cap and is treated as malformed). Tntegration testing hit this 50 session limit and failed. (Was failing our internal but also the openbmc-test-automation robot suite) I had originally implemented a solution as a "trusted reader" with no limit ( https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90138 ); however, the security implications of "no limit" weren't attractive. This area may be refactored in the near future to represent each session as a distinct json file. This value bump gets us past the immediate needs without introducing a lot of churn in code that will be refactored. Change-Id: Ifd3514bd8ee15c8bdf1b6c2119451a2965801671 Signed-off-by: Rick Yazwinski

Flag long lambdas

2026-07-01T17:10:08+00:00

Long lambdas have been documented as an anti-pattern for some time.[1] Despite this being generally understood, bmcweb has a long ways to go cleaning these up, and routinely code is submitted in violation of this anti-pattern. Invent an ast-grep rule that can identify when new examples of this anti-pattern are added, and ignore the existing 200+ examples that are in the codebase already using ast-grep ignore. These flags will give us something to search for as we clean this up, and will help to prevent new instances from being added unintentionally. [1] https://github.com/openbmc/docs/blob/master/anti-patterns.md#very-long-lambda-callbacks Tested: Comment only change. ast-grep passes. Manually removing an ast-grep ignore flag shows as a failure in ast-grep scan Change-Id: I77d634a393884969f184d2c39c02cc08288d5a29 Signed-off-by: Ed Tanous

Fix socket reuse in HTTP server accept loop

2026-06-24T22:41:58+00:00

bmcweb HTTP server accept handling had a critical bug where a single socket pointer was reused across multiple acceptors, causing undefined behavior and potential crashes. 1. Move socket creation into doAcceptOne() to ensure each acceptor creates its own unique socket instance. 2. Pass acceptor pointer to afterAccept() callback to track which acceptor completed the accept operation. 3. Replace doAccept() call with doAcceptOne() in afterAccept() to resume accepting on only the specific acceptor that handled the connection, not all acceptors. This ensures proper socket lifecycle management and prevents race conditions from shared socket instances. Tested: HTTP server accepts connections correctly with multiple acceptors (HTTP/HTTPS) without crashes or undefined behavior. Change-Id: I0540802cdd682e8e7d7312d6edfd5651bf09378a Signed-off-by: Kokilambal Varadhan