I’ve been noticing an issue with a web application we have where our application’s code that handles file uploads would intermittently encounter file upload error 3. I wasn’t sure how our users were triggering this error but I do know that the ones who did would be uploading files through an unstable or slow internet connection (mobile hotspots, public wifi, etc). So I tested this by using Chrome Dev Tools’ throttling feature (fast 3g) and uploading a 10mb file that would take somewhere around a minute or more to complete. We use the Dropzonejs library to handle uploads by the way with no chunking whatsoever. After exactly 22 – 23 seconds, the connection always seems to get aborted but Apache still proceeds to handle the incomplete request body it receives and passes it to PHP, leading to a partial upload error.
I can’t seem to figure out what is causing this to happen. PHP config has max_execution_time and max_input_time set to 0 and -1 respectively. Post and upload max sizes are set relatively high and well, the file upload size doesn’t even seem to matter. As long as the upload request takes longer than 22 – 23 seconds, the problem occurs. I tried disabling mod_reqtimeout and it didn’t make a difference. Other things I’ve tried are tinkering with the apache Timeout value and disabling keepalive and it still gives me issues a little after 20 seconds always (that time comes from the browser’s network tab).
I don’t see anything in apache’s error logs and the access logs make these requests appear legit, since apache still continues to handle the incomplete request like normal.
I initially thought it might be dropzonejs killing the ajax request connection but I have also tested the same code on my local dev environment which uses laradock (software versions will be slightly different. Still both apache 2.4 and php 7.2) and I cannot replicate the issue, so it couldn’t be a client-side problem.
2
Answers
Looks like it was mod_reqtimeout stopping my post requests. I think my apache changes just weren't propagating fully when I initially tried disabling it (I'm guessing due to a mix of me using a graceful restart and having keepalive enabled).
We had the same issue and solved thanks to this question.
However there is no need to entirely disable the module.
The problem is caused by this bug in Apache 2.4.39:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63325
As suggested in the bug report you can explicitly set the default in Apache config file.