Zephyr OS HTTP/1 POST Responses: Do Not Use an Empty Final Callback to Wait for a Worker

An empty response from a dynamic HTTP callback is not necessarily a request to try again later. In the Zephyr OS v4.4.0 HTTP/1 POST path, leaving the response empty when the final request data arrives can complete the response instead of preserving a deferred application operation.

This matters when a device accepts a command, starts background work and expects to send the result after that work finishes. Review the request-delivery state and response-generation state separately before choosing that design. The cases below are proposed checks, not results from a deployed product.

Distinguish the two directions of progress

The versioned server interface describes REQUEST_DATA_MORE and REQUEST_DATA_FINAL as request-body delivery progress. TRANSACTION_COMPLETE and TRANSACTION_ABORTED are terminal notifications. The response context separately carries status, headers, body length and final_chunk.

The callback's successful return permits the server to send the response data supplied for that invocation. It does not, by itself, establish an asynchronous completion subscription for an unrelated worker. Likewise, the final request fragment does not prove that the device has finished applying the command contained in that request.

In a hypothetical calibration endpoint, receiving the last configuration byte, starting calibration and producing the calibration result are three different events. A trace that logs only “final callback” cannot distinguish them.

Understand what counts as an empty final response

The shared completion predicate first requires REQUEST_DATA_FINAL. At that stage, it recognizes either final_chunk or a response with zero status, zero header count and zero body length as final. With REQUEST_DATA_MORE, that predicate does not report final even if final_chunk is set.

For review purposes, inspect all these fields together. Merely setting a body pointer without a positive body length does not make that body available to transmit. Conversely, a nonzero status or header count is meaningful even when the application has no body bytes.

The useful question is not whether the callback “returned nothing.” It is which request state accompanied exactly which response fields. Capture those values in a disposable test rather than inferring the decision from an empty browser page.

Trace the POST handler before adding a background worker

The HTTP/1 implementation zeroes the response context before invoking the POST callback. It initially sends a response only when one is provided. After the last request data, it can call the callback repeatedly until the response is final. At message completion, if headers have still not been sent, it generates a default response and terminates the transaction.

Therefore, a callback that starts a worker and leaves every response field zero on the final request invocation can take the completion path. Waiting for the worker to fill that old callback context later is not an established contract of this path.

A design alternative is to acknowledge an accepted operation and expose its result through a separate, explicitly specified retrieval mechanism. That is an application protocol decision, not a claim that every command should return success before it finishes. Define acceptance, completion and failure responses according to the device's actual requirements.

Test the state boundary directly

Exercise a POST body delivered in several fragments. Leave the response empty during an intermediate fragment, then compare an intentionally final response with an accidentally empty response on the last fragment. Record callback status, response fields and whether the terminal notification occurs.

Also test the case where work fails before the application has committed to its response. Do not substitute a late result for the status already sent to the client. Keep GET handling, HTTP/2 behavior and any future server revision outside this conclusion until their own control paths are checked. A precise POST completion test is more useful than assuming every dynamic callback supports deferred output.