Set default maxChunkSize to 99 MB #5813
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR:
Rationale: PR #3600 was suggested since the old value of 100 MB was arguably "not enough for modern usage". I disagree with that statement entirely, majority of people do not have ISP-grade upload speeds at home, and the default option should be adjusted accordingly to majority of users rather than some very specific setups where chunking could be a bottleneck. I do agree that chunking could result in bottleneck, and for those handful amount of setups, it's already possible to set max chunking size higher. However, there is a very good reason why chunking is for example set only to 80 MB by default in iOS app, and why it exists in general - so uploads can be retried if disrupted. 100 MB of value aligns with Cloudflare default maximum body, and I'd say there is a very good reason why they set it like that. This is why this PR sets the upper limit to 99 MB, extra megabyte just to make sure that we do not exceed the limit in regards to other data we send, such as the request URL, headers (including authorization), among others.
It's nice to mention that there is PR #4826 which addresses this issue in even better (in my opinion) way. However, that PR is in limbo state since almost a year, requires additional code review, perhaps further fixes, while a lot of people are suffering from this, being forced to change default values sometimes on even hundreds of different machines, purely because the default value was set too high for cloudflare-specific (and probably not only) usage.
Personally as unrelated developer who stumbled upon #4278 and was affected by it, I believe we should go back from 1000 MB to 100 (99) MB at least for time being, until there is better solution like #4826, without having another year or 10 with people being forced to set every single desktop nextcloud client purely because the hosting owner decided to use Cloudflare or other CDN in front of it. I'd rather have slower but working speeds for everybody by default, rather than only 82% of setups working at all, at least according to general statistics such as https://w3techs.com/technologies/details/cn-cloudflare
I understand that this can be controversial decision, that Nextcloud should not be limited by artbitrary limits set by third-party CDNs and so on and so on, I agree, but it's not like this change stops anybody from doing anything, rather, it fixes the issue that affects a lot of people using Cloudflare (among other) CDNs, and I'm strongly against software that expects from me to fix it before I'm even able to use it. If that was server setting, I'd have another opinion - if server owner decided to use Cloudflare, he can also notify the clients about the limit, simple. However, this isn't server setting, we can't tell clients what value should be used, and the burden of adapting all the clients to match it is in my opinion not worth increasing performance in very specific setups that do not handle chunking as effectively as they could.
One potential improvement is to find out the limit dynamically like in #4826. Another is to introduce server-sided max chunk size limit and use
MIN(server, client)
as the final one. Both of those however require knowledge and more work than this PR, I don't have enough of time to dig into it myself either, so I understand other people, this is why I believe we should for now just change the defaults, and put potential enhancements as a wishlist for when somebody is willing to improve nextcloud in this aspect.Thank you in advance for considering this PR.