The changes to mod_reqtimeout made in 2.4.39 (as per bug 61310) have no default for the body_min_rate parameter, contrary to both the documentation and the behaviour of <=2.4.38. This means that if no explicit RequestReadTimeout statement is made in httpd.conf, by default the server will return a 408 timeout after 20s even if the client is actively sending data to the server (e.g. for a large file upload). I found this bug when users reported they could no longer upload files to our websites. I have tested under a fresh install of both Linux (Ubuntu) and FreeBSD (11 and 12). While some distributions such as ubuntu explicitly define RequestReadTimeout in their default config, the documentation states the default is body=20,minrate=500 (which was correct for <=2.4.38). This means 2.4.39 breaks file uploads where the documented default is relied on, which is why I've marked this bug as major. WORKAROUND: Explicitly set the default: RequestReadTimeout handshake=0 header=20-40,MinRate=500 body=20,MinRate=500 in httpd.conf and reload. It looks like the changes made to mod_reqtimeout in 2.4.39 were fairly major in order to incorporate the new "handshake" stage, so although I've tried, I'm afraid I'm unable to see where the problem might lie. Sorry I can't be more help diagnosing this. Many thanks.
Thanks for the report. Do you set RequestReadTimeout partly (e.g. body= but no ,MinRate=) or not at all?
I would assume that defining a simple body=20 would automatically stop minrate from working, so no: my report is based on when there are no RequestReadTimeout declarations in any conf file (I grepped thoroughly to confirm). Oliver
Created attachment 36514 [details] Fix reqtimeout macros lowercase The macros MRT_DEFAULT_*_MIN_RATE which contain the default value were partially made lowercase for some magic, unfortunately the ones tested in reqtimeout_hooks() were not renammed, hence the bug. Could you please try with this patch?
Fixed in r1857129, will propose a backport to next 2.4.x.
Huge thanks for the quick work, I can confirm the patch fixes the issue.
*** Bug 63329 has been marked as a duplicate of this bug. ***
*** Bug 63617 has been marked as a duplicate of this bug. ***
This has been backported in 2.4.x in r1859376. This is part of 2.4.40.