Inleiding
Wat moet je doen als een up-en-download service die je zelf gebouwd hebt, plotseling niet meer werkt? Juist: je gaat op zoek met alle middelen die je ter beschikking hebt. Uiteindelijk kwam ik een onverwachte oorzaak op het spoor...
Symptomen
Het uploaden van grote bestanden (meer dan 1GByte) ging van de ene op de
andere dag niet meer. In de browser verscheen HTTP status 413
. Later
zag ik in de logs van de webserver soms HTTP status 405
. Het leek er op
dat na een bepaald aantal seconden de upload werd afgebroken. Eerste
gedachte: één of andere timeout. Dus, gauw met ini_set
of in php.ini
de timeouts opgekrikt.
ini_set('max_input_time', '10800');
ini_set('max_execution_time', '10800');
Dit had geen resultaat. Dus ging ik op zoek naar andere timeouts die in
de applicatie een rol spelen. Ik zag een HTTP status 502 Bad gateway
en kwam uiteindelijk uit bij Traefik: een netwerkrouter binnen de
Docker-setup. De betreffende docker-compose
instelling luidt:
--entrypoints.<name>.transport.respondingtimeouts.readtimeout:
ReadTimeout is the maximum duration for reading the entire request,
including the body. If zero, no timeout is set. (Default: 60)
Ik zette ook deze waarde op 0
, maar helaas. De upload werd steeds weer
afgebroken na een schijnbaar vast aantal seconden.
Tot slot vond ik in het logbestand van de Apache webserver de volgende melding:
[Thu Mar 06 14:39:19.316634 2025] [http:info] [pid 376321:tid 376321]
[client ...] AH01588: Requested content-length of 1158120346 is larger
than the configured limit of 1073741824
Een limiet op het aantal overgedragen bytes? Die had ik nog nooit gezien, zeker niet van 1073741824 oftewel 1GByte...
Oorzaak en oplossing
Toen ik met deze specifieke foutmelding op internet ging zoeken kwam ik een bugreport op opendev.org tegen waar haarfijn stond uitgelegd wat er aan de hand was. Vrij vertaald:
In Apache 2.4.53 en ouder was de LimitRequestBody limiet ingesteld op oneindig, en dus niet actief. In versie 2.4.54 is deze limiet op 1GByte ingesteld en dus actief. Na een update naar deze versie, ontvangen gebruikers mogelijk een HTTP 413 foutcode.
Aldus vond ik in de documentatie van Apache de beschrijving van
de limiet en dat deze inderdaad standaard op 1073741824 bytes staat
ingesteld. Éénmaal aangepast in httpd.conf
was het euvel verholpen.
Epiloog
Achteraf heb ik mijn bovengenoemde downloadservice onder de motorkap
volledig omgebouwd zodat de upload niet meer in één stuk wordt gePOST
.
In plaats daarvan wordt de upload met behulp van Quentin Buzuts
huge-uploader in stukjes van maximaal 10MByte gehakt, overgedragen
en later op de server weer samengevoegd. Zo wordt zo'n beetje elke
upload-limiet omzeild.
Misschien stof voor een volgend artikel... :-)