Refresh lock tocken does not modify Timeout value when no timeout value is passed or no body given

[davitol]

Steps to reproduce

1. Create a file
2. Lock the file and save lock-token.

curl -u admin:admin -H Timeout:Second-120 -H 'If: (<opaquelocktoken:e249539f-a66f-4dcc-85e7-9f8b00399df6>)' -X LOCK http://10.40.40.222:9681/remote.php/webdav/WindowsNetworkDrive/User/asf.txt

3. Refresh the lock-token (LOCK with empty body) and check the Timeout value:

curl -u admin:admin -H 'If: (<opaquelocktoken:e249539f-a66f-4dcc-85e7-9f8b00399df6>)' -X LOCK http://10.40.40.222:9681/remote.php/webdav/WindowsNetworkDrive/User/asf.txt

Info related refreshing lock-token in the RFC https://tools.ietf.org/html/rfc4918#page-21 :

Refreshing Write Locks

   A client MUST NOT submit the same write lock request twice.  Note
   that a client is always aware it is resubmitting the same lock
   request because it must include the lock token in the If header in
   order to make the request for a resource that is already locked.

   However, a client may submit a LOCK request with an If header but
   without a body.  A server receiving a LOCK request with no body MUST
   NOT create a new lock -- this form of the LOCK request is only to be
   used to "refresh" an existing lock (meaning, at minimum, that any
   timers associated with the lock MUST be reset).

   Clients may submit Timeout headers of arbitrary value with their lock
   refresh requests.  Servers, as always, may ignore Timeout headers
   submitted by the client, and a server MAY refresh a lock with a
   timeout period that is different than the previous timeout period
   used for the lock, provided it advertises the new value in the LOCK
   refresh response.

Expected behaviour

Refresh is supposed to extend the timeout somehow. We could maybe reset the value "oc_persistent_token.created_at"

Actual behaviour

Timeout is not modified.

curl -u admin:admin -H 'If: (<opaquelocktoken:e249539f-a66f-4dcc-85e7-9f8b00399df6>)' -X LOCK http://10.40.40.222:9681/remote.php/webdav/WindowsNetworkDrive/User/asf.txt

<?xml version="1.0"?>
<d:prop xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
 <d:lockdiscovery>
  <d:activelock>
   <d:lockscope>
    <d:exclusive/>
   </d:lockscope>
   <d:locktype>
    <d:write/>
   </d:locktype>
   <d:lockroot>
    <d:href>WindowsNetworkDrive/User/asf.txt</d:href>
   </d:lockroot>
   <d:depth>infinity</d:depth>
   <d:timeout>Second-607</d:timeout>
   <d:locktoken>
    <d:href>opaquelocktoken:e249539f-a66f-4dcc-85e7-9f8b00399df6</d:href>
   </d:locktoken>
   <d:owner>admin</d:owner>
  </d:activelock>
 </d:lockdiscovery>
</d:prop>

Server configuration

Operating system:
Ubuntu 18.04
Web server:
Apache2
Database:
MySQL
PHP version:
7.1
ownCloud version: (see ownCloud admin page)
10.1 RC1
Updated from an older ownCloud or fresh install:
fresh
Where did you install ownCloud from:
tarball
Are you using external storage, if yes which one: local/smb/sftp/...
no
Are you using encryption: yes/no
no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
no

@PVince81 @individual-it FYI

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are #33778 (Persistent lock timeout value is "Second-" when not specified.), #33846 (Persistent lock timeout value must be remaining time), #1199 (DAV locking doesn't work.), #34100 (Fix persistent lock timeout behavior), and #15779 ('Modified' span does not hide when selecting files or folders).

[jvillafanez]

Adding the timeout header, it works fine with OC 10.3.1 (at least).
Without the timeout header, I think it's either an issue in sabre-dav or "it works as designed".
The target code is around https://github.com/sabre-io/dav/blob/master/lib/DAV/Locks/Plugin.php#L192-L227.

Another option is that ownCloud is wrong about the timeout set for the lock: the timeout should be fixed and shouldn't decrease (maybe only for the propfind? - but we can't distinguish both cases), so if we set a timeout of 300 secs, and then request the lock information after 50 secs, we still get the 300 secs timeout (full timeout) instead of the 250 secs (remaining timeout). At least this way, the refresh would work properly by setting a new timeout of 300 secs.