AbstractWebApplication::respond() sends a response body on 204 No Content, violating RFC 9110 §15.3.5 #48553

Summary

Every successful API DELETE (and any other action that sets a 204 status) still gets a non-empty response body. Per RFC 9110 §15.3.5, a 204 response must not contain a message body.

Root cause

• CMSApplication::execute() (libraries/src/Application/CMSApplication.php:320-324) unconditionally calls $this->render() after doExecute() returns — the only check is $this->document instanceof Document, no status-code check at all.
• ApiApplication::render() (libraries/src/Application/ApiApplication.php:150-154) unconditionally does $this->setBody($this->document->render(...)).
• AbstractWebApplication::respond() (libraries/vendor/joomla/application/src/AbstractWebApplication.php:364) unconditionally does echo $this->getBody(); — no exemption for 204 (or 304, same RFC section).

Steps to reproduce

DELETE any API-writable resource successfully, e.g.:

DELETE /api/index.php/v1/content/articles/:id

Response status is 204, but the body is non-empty (a JSON:API document).

Confirmed deterministically under PHP's built-in dev server (php -S) with a strict HTTP/1.1 client (Playwright's Node HTTP client) — the client fails to parse the response at all:

Error: apiRequestContext.delete: Parse Error: Data after `Connection: close`

Apache is more lenient about the extra bytes and the request completes normally, which is likely why this has gone unnoticed — it surfaces specifically under stricter HTTP/1.1 clients/servers, not universally.

Expected result

A 204 response has no body, per spec, regardless of client/server strictness.

Actual result

A 204 response carries a JSON:API body, which breaks strict HTTP/1.1 clients and is a spec violation even where it's silently tolerated.

Impact

Framework-wide — affects every writable API resource across every component, not anything component-specific.

Suggested fix

respond() should skip sending a body (and ideally the Content-Type header) when the status code is 204 or 304.

System information

Found via a component's own CI running Package install + E2E (Joomla 5) against Joomla 5.4.x; traced through to current 5.4-dev/6.1-dev core, same code shape in both.

Reported by someone who contributes to Joomla core occasionally, not a cold outsider — open to picking up the fix if that's useful, happy to let someone else run with it otherwise.