; The php:8.4-apache image deliberately ships no active php.ini (only the
; php.ini-development / php.ini-production samples), so PHP falls back to its
; compiled-in defaults: display_errors=On, display_startup_errors=On and
; log_errors=Off. That combination took production down on 2026-09-02.
;
; A bot POSTed to /cgi-bin/quick/quick.cgi with Content-Type: multipart/form-data
; and no boundary. PHP emits "Missing boundary in multipart/form-data POST data"
; at request *startup*, before a single line of application code runs — so
; Laravel's own ini_set('display_errors', 'Off') in HandleExceptions::bootstrap()
; is far too late to suppress it. The warning was printed, output had already
; begun, and every header() call after that failed:
;
;   $response->send() -> header() -> "Cannot modify header information"
;     -> ErrorException thrown out of handleRequest(), outside the HTTP
;        kernel's try/catch -> the set_exception_handler() last resort tries to
;        render a 500 -> header() again -> FatalError.
;
; Two quieter problems came with the same defaults: a printed warning leaks
; absolute server paths to whoever triggered it, and log_errors=Off meant these
; startup warnings were recorded nowhere at all.
;
; error_log is deliberately left unset. Under mod_php that routes errors to the
; SAPI logger — Apache's error log — which apache2-foreground already forwards
; to the container's stderr, so they land in `docker logs` with everything else.
;
; This applies in local dev too, and nothing is lost there: Laravel's own error
; page (APP_DEBUG=true) does not read display_errors, and the startup warnings
; that used to be printed are now logged rather than discarded.
display_errors = Off
display_startup_errors = Off
log_errors = On