fix(docker): raise PHP post_max_size for default 20MB upload chunks

Dockerfile

@@ -10,6 +10,11 @@ RUN install-php-extensions iconv gd pdo pdo_mysql pdo_pgsql pgsql \
     && apt-get clean \
     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
 
+# PHP_INI_DIR is set by the official php:8-apache image to /usr/local/etc/php
+# and has been stable across PHP majors. Using the env var documents intent
+# and follows any future upstream change to the path automatically.
+COPY docker/librespeed-php.ini ${PHP_INI_DIR}/conf.d/99-librespeed.ini
+
 # Prepare files and folders
 RUN mkdir -p /speedtest/
 

Dockerfile.alpine

@@ -24,6 +24,23 @@ RUN apk add --quiet --no-cache \
 RUN ln -sf /dev/stdout /var/log/apache2/access.log && \
     ln -sf /dev/stderr /var/log/apache2/error.log
 
+# This image has two PHP installs: the FROM php:8-alpine binary (conf.d at
+# /usr/local/etc/php/conf.d) and the apk-installed php-apache2 (conf.d at
+# /etc/phpXX/conf.d). mod_php uses the apk one — glob /etc/php*/conf.d to
+# find it without pinning the PHP major.
+COPY docker/librespeed-php.ini /tmp/librespeed-php.ini
+RUN set -eu; \
+    scan_dir=""; \
+    for d in /etc/php*/conf.d; do \
+      [ -d "$d" ] && scan_dir="$d" && break; \
+    done; \
+    if [ -z "$scan_dir" ]; then \
+      echo "ERROR: no /etc/php*/conf.d directory found; apk php-apache2 install layout may have changed" >&2; \
+      exit 1; \
+    fi; \
+    install -D -m 0644 /tmp/librespeed-php.ini "$scan_dir/99-librespeed.ini"; \
+    rm /tmp/librespeed-php.ini
+
 # Prepare files and folders
 RUN mkdir -p /speedtest/
 

docker/librespeed-php.ini

@@ -0,0 +1,18 @@
+; LibreSpeed-recommended PHP override.
+;
+; speedtest_worker.js uploads in 20 MB chunks by default
+; (xhr_ul_blob_megabytes: 20). PHP's stock post_max_size = 8M rejects
+; every chunk: PHP emits a "POST Content-Length ... exceeds the
+; limit" startup warning and prevents empty.php from sending its
+; response headers (Cache-Control, Pragma, Connection, and CORS
+; under ?cors).
+;
+; The upload throughput number itself is unaffected — the worker
+; reads bytes-on-wire from xhr.upload.onprogress, not the response
+; body — but the response from empty.php is otherwise malformed.
+;
+; 32M is the next round number above the worker's 20M default; it
+; leaves headroom for operators who tune xhr_ul_blob_megabytes
+; upwards.
+
+post_max_size = 32M