Scouring the code, I found a regression that might've caused #1395 (closed). When !2290 (merged) was merged, the download logic was refactored to use enum values rather than pure integers, which is a good thing from a maintenance standpoint. Problem is that the numeric values were changed, so YES became 0 instead of 1, NO became 1 instead of 2 and TOOLARGE became 2 instead of 0. This would've worked fine, if it weren't for the fact that the code for the third case, TOOLARGE, was commented out beforehand since it expanded to 0, which is the default value.
Obviously, this is a problem since 0 now means YES, so the client would interpret it as that even if was too large for the server to be acceptable, and proceed with the download. At that point, the server would refuse to send any data since it wasn't configured for it, but it didn't actually inform the client, so the client would be stuck waiting for data which would never be sent at all.
Uncommenting that code and adjusting to use the enum values seems to fix the problem, although it's not confirmed if it fixes #1395 (closed) or not.
(cc @Jisk, can you pre-merge this and see if it fixes #1395 (closed)?)