fix: prevent postprocessor/errorHandler from overriding HTTP_STATUS_UNFINISHED

[Copilot]

Commit 62cd137 introduced HTTP_STATUS_CLOSE support but changed customHttpHandler(service->postprocessor) to capture its return value into status_code, overwriting HTTP_STATUS_UNFINISHED (0). When a handler like sendLargeFile returns HTTP_STATUS_UNFINISHED and a postprocessor returns resp->status_code (200), the connection is treated as complete — sending a premature empty response and closing/resetting the connection.

Before (broken):

if (service->postprocessor) {
    status_code = customHttpHandler(service->postprocessor);  // overwrites UNFINISHED(0) → 200
    if (status_code == HTTP_STATUS_CLOSE) { ... }
}

After (fixed):

if (service->postprocessor) {
    int pp_status_code = customHttpHandler(service->postprocessor);  // local var
    if (pp_status_code == HTTP_STATUS_CLOSE) { ... }
}

• Use local variables for both postprocessor and errorHandler return values, only checking for HTTP_STATUS_CLOSE without clobbering status_code
• Same fix applied to errorHandler which had the identical pattern

[Copilot]

Pull request overview

Fixes a regression in HttpHandler::HandleHttpRequest() where postprocessor/errorHandler return values could overwrite HTTP_STATUS_UNFINISHED (0), causing async/streaming handlers to be treated as complete and leading to premature response send/connection close.

Changes:

• Stop assigning postprocessor return value back into status_code; only treat HTTP_STATUS_CLOSE as special.
• Apply the same “don’t clobber status_code” handling to errorHandler, also only treating HTTP_STATUS_CLOSE as special.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

errorHandler return value is now ignored unless it is HTTP_STATUS_CLOSE. This breaks the case where errorHandler is an async handler (or otherwise returns HTTP_STATUS_NEXT/UNFINISHED to indicate response will be written later): HandleHttpRequest() will still return the original error code, causing the caller to immediately SendHttpResponse() and potentially send an empty/partial response before the async error handler runs. Consider still honoring err_status_code == HTTP_STATUS_NEXT (without overwriting an existing HTTP_STATUS_NEXT with a non-zero code).

Suggested change

	}
	}
	if (err_status_code == HTTP_STATUS_NEXT) {
	status_code = HTTP_STATUS_NEXT;
	}

[Copilot]

postprocessor return value is now ignored unless it is HTTP_STATUS_CLOSE. This removes the previous ability for postprocessor to return HTTP_STATUS_NEXT/UNFINISHED (including when implemented as http_async_handler, where invokeHttpHandler returns HTTP_STATUS_NEXT) to defer response sending. With the current code, HandleHttpRequest() will likely return a non-zero status and the caller will SendHttpResponse() immediately. Consider propagating pp_status_code == HTTP_STATUS_NEXT into status_code while still preventing a non-zero postprocessor return from clobbering an existing HTTP_STATUS_NEXT.

Suggested change

	}
	}
	if (pp_status_code == HTTP_STATUS_NEXT && status_code != HTTP_STATUS_NEXT) {
	status_code = HTTP_STATUS_NEXT;
	}

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.