[Libreoffice-bugs] [Bug 132460] New: WebDav ephemeral lock timeout negotiation has a feedback-loop

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=132460

            Bug ID: 132460
           Summary: WebDav ephemeral lock timeout negotiation has a
                    feedback-loop
           Product: LibreOffice
           Version: 7.0.0.0.alpha0+ Master
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: framework
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: jean-louis.fuchs at adfinis-sygroup.ch

Description:
WebDAV servers do not return the lock-timeout the lock was set up with; they
have to return the remaining time. There are WebDAV servers that return a lower
timeout. Two examples [2] [3]. Other servers probably reuse the same timestamp
for the whole request and are therefore not subject to that problem. (This
might
even be incorrect if the request takes very long.)

Updating the lock-timeout with the value returned by the server decreases the
timeout until it reaches zero.

LibreOffice request               SERVER response
LOCK(180)         ->              LOCK(60)
LOCK(60)          ->              LOCK(59)
LOCK(59)          ->              LOCK(58)
...
0: no LOCK header ->              FAIL

If we do not update the timeout in NeonSession::LOCK() only the initial setup
updates the timeout.

LibreOffice request               SERVER response
LOCK(180)        ->               LOCK(60)
LOCK(60)         ->               LOCK(59)
LOCK(60)         ->               LOCK(59)
...

It is essential that lastChanceToSendRefreshRequest uses the timeout returned
by
the server; after it calculated the deadline, we reset the timeout.

The maintainer of neon confirmed that the timeout should stay the same after
the
initial setup. [4].

[1] https://tools.ietf.org/html/rfc4918#section-6.6
[2] https://www.alfresco.com/
[3] https://github.com/mar10/wsgidav
[4] https://github.com/notroj/neon/issues/12


Steps to Reproduce:
1. webdav-neon/webdavcontent.cxx to use a timeout of 12 seconds

diff --git a/ucb/source/ucp/webdav-neon/webdavcontent.cxx
b/ucb/source/ucp/webdav-neon/webdavcontent.cxx
index 3113b3c1f5f1..4a0a6b437fc3 100644
--- a/ucb/source/ucp/webdav-neon/webdavcontent.cxx
+++ b/ucb/source/ucp/webdav-neon/webdavcontent.cxx
@@ -3290,7 +3290,7 @@ void Content::lock(
             ucb::LockType_WRITE,
             ucb::LockDepth_ZERO,
             aOwnerAny,
-            180, // lock timeout in secs
+            12, // lock timeout in secs
             //-1, // infinite lock
             uno::Sequence< OUString >() );

Of course you can reproduce the problem without that patch, but you have to
wait very long. (180 * 180 / 2 seconds)

2. Run https://github.com/mar10/wsgidav

3. Connect and save a file

4. Close LibreOffice

5. Load the file and watch the wsgidav log

Actual Results:
The lock-request timeouts decrease.

Expected Results:
The lock-request timeout should stay the same.


Reproducible: Always


User Profile Reset: No



Additional Info:
Also observed on a version of Alfresco. I have no details on that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200427/d84ee2ce/attachment-0001.htm>