In some owncloud server setups multiple concurrent connections for the
same session are not supported: owncloud/core#11153
This causes issues with multiple uploads and downloads. A usual symptom
is the quota job failing and the sync aborting.
This workaround lets activity on the propagator's GET and PUT jobs
reset the timeout of all network jobs. That way, queries like the quota
job would not time out while a large up/download is in progress.
(cherry picked from commit 2eec85a97c)
* If a 416 is returned and we used a Range header, try again
from scratch.
* The direct URL logic was also inconsistent for resumed downloads:
it sent the Range header but didn't check the returned
Content-Range header correctly. Now resuming is disabled for
direct URL downloads.
(cherry picked from commit 48d3c75745)
It is not enough to only implement it for the QNAM returned
by the ShibbolethCredentials, because we sometimes need it
when we have no valid credentials set (and are using dummy
credentials in the course). The main use case is the
Webview opened by Shibboleth for FBA.
But as a side-effect, we can use it to handle auth requests
from the updater and other places.
(cherry picked from commit 1544606bf0)
Conflicts:
src/CMakeLists.txt
src/creds/shibbolethcredentials.h
It is called automatically by QWizard and do not need to be called explicitly
But setVisibla(false) don't really have an effect there since show() is going
to be called on the page
When the url do not have a path (for example: "http://example.com" as
opposed to "http://example.com/"), its path is not a prefix of the
root path of the cookie (usually '/')
By adding the dav path, we make sure the URL has a path.
This made a bug when the owncloud url was just a domain name and did not
have a path
Otherwise the buffer might fill up too quickly and get too large and consume
too much memory which could lead to crash in extreme cases
Should fix issue #1974
When using the "Limit automatically" limit, we wait for 25% of the time
it took to upload something.
However, if we go to sleep while uploading, the time it took to upload may take
days. And waiting for 25% of a day is too long.
So never wait for more than 10 seconds
This may be related to issue #1880
If the local folder changes, the sync has to be reinitialized as
well. Until now we did not detect that, which led to the case that
the sync folder was not reinitialized in case only the local folder
changed in the setup dialog.
