Add more timeout configs in the nginx-root-sample file

[julien-nc]

To later make these timeout values configurable

[MichaIng]

What issue is this solving? Defaults for all 4 values are 60 seconds: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout

Allowing connections resp. individual packets to hang for 1 hour might cause other issues if the backend resp. client remain unresponsive, like max threads/connections running full, connection queries running full, potentially memory issues etc. In slow network environments it might be a workaround to increase these timeouts, so it might be not a bad idea to expose those settings, but I would not implement it with a 60x higher default.

In any case, if wanted, please add those to the sub dir config as well, they should be kept in sync.

[oleksandr-nc]

Can we try first if 30 minutes is enough for very large files? And maybe make an additional comment in docs that this is related for uploading of very large files with webui?

[julien-nc]

@MichaIng Thank you for the feedback.

The precise issue that motivates this change is that uploading big files fails with:
1171 upstream timed out (110: Connection timed out) while reading response header from upstream, client: x.x.x.x, server: , request: "MOVE /remote.php/dav/uploads/admin/web-file-upload-5e685f6e7e669798/.file HTTP/1.1", upstream: "fastcgi://x.x.x.x:9000", host: "a.b.c.d"

The root cause might be a slow NFS filesystem. This is indeed a workaround but that might be the only option in some cases.

I've adjusted those values back to their default: 60s. The main goal is to make them configurable in an enterprise-aio setup.

[MichaIng]

And maybe make an additional comment in docs that this is related for uploading of very large files with webui?

According to the docs, these settings are not affecting the max transfer time, but only the time it takes to (re)connect to proxy/client, respectively the time between two packets (read resp write operations). So it is about if backend/client turn unresponsive, how long the connection shall wait idle before giving up.

The precise issue that motivates this change is that uploading big files fails with:

Hmm, and that example was actually hanging for such a long time, or did only the proxy handler expect response headers while the backend was synchronously receiving/writing the large file? Also do really all 4 settings need to be adjusted for this very specific case, or is proxy_connect_timeout alone sufficient (which seems to be the one responsible for the exact error you pasted)?

Maybe this can be better solved in Nextcloud code (mid-term at least). I am no WebDAV expert, but maybe there is a way to send the expected response headers (and in case keep sending some "I am alive" signals) while the backend is waiting for the slow filesystem or while uploads/writes to it are done.

I've adjusted those values back to their default: 60s. The main goal is to make them configurable in an enterprise-aio setup.

Understood. I guess they could be even kept commented by default in this case, so they have a place in the config, but need to be uncommented to override Nginx or parent config defaults.

[julien-nc]

do really all 4 settings need to be adjusted for this very specific case, or is proxy_connect_timeout alone sufficient (which seems to be the one responsible for the exact error you pasted)

@MichaIng Not knowing that for sure is a good reason IMO to allow the admins to change any of those values in enterprise-aio.

@szaimen Is it fine to have those values commented for the rest of the work in enterprise-aio to have new env vars to set those vaues?

[szaimen]

@szaimen Is it fine to have those values commented for the rest of the work in enterprise-aio to have new env vars to set those vaues?

yes. It is fine

[szaimen]

LGTM, thanks!