tree ba05e048a47e0b9f6c8af824f0c77f10d950b49f
parent 090ab8e1042e14f7e5e02572ae2a2102677f1f00
author Ed Tanous <ed@tanous.net> 1715914367 -0700
committer Ed Tanous <ed@tanous.net> 1716919390 +0000

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>