libsync: use the new webdav url if the server reports it #5332
Conversation
| @@ -57,6 +57,11 @@ Account::~Account() | |||
|
|
|||
| QString Account::davPath() const | |||
| { | |||
| if (capabilities().chunkingNg()) { | |||
There was a problem hiding this comment.
Why do you need this "if" here? I might want to use it for bundling also. What do you think?
There was a problem hiding this comment.
EDIT: oh sorry, code in github wrapped and have not seen the rest. Of course it is good.
There was a problem hiding this comment.
But been mostly thinking about creating just separate function instead of "if", but in this case it makes no sense. It is all good. For bundling I will just need to work-around this. Because I would need that String (the same) anyways, but only for uploaded files.
There was a problem hiding this comment.
Because both chunkingng and the new dav url need to be enabled at the same time! (the old chunking don't work with the new url, and the new chunking don't work with the old one)
Maybe the capability should be renamed "useNewDavPath()"
There was a problem hiding this comment.
"filesDavPath" is ok with me.
|
👎 for now. Can you mention the issue ID in the commit? @michaelstingl @rperezb Please see the comment in the commit message 👍 if this is clarified |
|
@guruz in ownBrander we do have a variable for the users to update the webdav end point:
If i got this right, within the version 2.3.0, this is not going to be possible any more, |
|
When merge is planned? Is it possible to create new function filesDavPath()? |
|
@rperezb , @michaelstingl : With the client 2.3.0 , the webDavPath ownbrander setting will only have any impact if the server is < 9.2 From owncloud 9.2, we will use the new dav system with a new URL scheme. If we want to keep an option, we need to make it smarter so we can configure it for all the possible end point. Depending on the use case of this setting, i suggest one of the following:
|
|
about how to proceed, let's see what @hodyroff or @felixboehm thinks, at the end, this was a requirement from customers. to sum up, we do have an option on the desktop client that allows clients to modify the webdav end point, instead of using the one by default (remote.php/webdav) is this needed to any customer? / do we want to keep this? |
The rules to select the webdav url are now: - If the server reports that the new chunking algorithm is working, always use remote.php/dav/files/<username> This capability can be overriden with an environment variable - Otherwise, use the dav path provided by the theme, which defaults to remote.php/webdav This means that with the newer server, the branding can no longer override the webdav URL. If there is still an usecase for the branding to do so, we need to find another way to override it. But it is now more complicated to configure as might need include the username and need different endpoint depending on the operations (chunks or not) Issue #4007
ogoffart
force-pushed
the
chunking-ng
branch
from
c659a9f to
a61d009
Compare
|
The option will still be working with server older than 9.2 |
|
I can't tell if we need to be able to configure webdav routes. |
The rules to select the webdav url are now:
If the server reports that the new chunking algorithm is working,
always use remote.php/dav/files/
This capability can be overriden with an environment variable
Otherwise, use the dav path provided by the theme, which defaults to
remote.php/webdav
This means that with the newer server, the branding can no longer override
the webdav URL. If there is still an usecase for the branding to do so, we
need to find another way to override it. But it is now more complicated to
configure as might need include the username and need different endpoint
depending on the operations (chunks or not)