plugin_file_include() (core/plugin_api.php) answers a matching If-Modified-Since with 304 Not Modified and no output. However, compress_handler_is_enabled() (core/compress_api.php) has already switched on zlib.output_compression via ini_set(), and PHP's zlib output handler emits a gzip stream (20 bytes: header, empty deflate block, trailer) even for an empty buffer. The raw response from php-fpm is:

Status: 304 Not Modified
Last-Modified: Wed, 16 Sep 2026 06:51:05 GMT
Content-Encoding: gzip
Vary: Accept-Encoding

<20 bytes of gzip>
RFC 9110 §15.4.5 forbids a body on 304. Apache and nginx silently drop it, so this went unnoticed. Caddy (Go net/http) refuses to write it and aborts the response:

{"level":"warn","logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response",
"uri":"/plugin_file.php?file=Calendar/calendar_filter.js",
"error":"writing: http: request method or response status code does not allow body"}
In the browser every plugin CSS/JS asset then fails with net::ERR_HTTP2_PROTOCOL_ERROR and the page renders unstyled. Since plugin_file.php sends Cache-Control: private, max-age=10800, the browser starts revalidating with If-Modified-Since about three hours after the first visit, so a MantisBT behind Caddy loses all plugin assets a few hours after each hard reload. Every plugin that serves files through plugin_file.php is affected.

Steps To Reproduce:

Additional Information: