test: fix TUS upload checksums

test: update expected-failure list

test: fix issue in expected failure list

test: fix OPTIONS scenarios

tests/acceptance/expected-failures-API-on-OCIS-storage.md

@@ -124,32 +124,21 @@ _ocdav: api compatibility, return correct status code_
 - [coreApiWebdavUploadTUS/checksums.feature:193](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L193)
 - [coreApiWebdavUploadTUS/checksums.feature:194](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L194)
 - [coreApiWebdavUploadTUS/checksums.feature:195](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L195)
-- [coreApiWebdavUploadTUS/checksums.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L197)
 - [coreApiWebdavUploadTUS/checksums.feature:196](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L196)
+- [coreApiWebdavUploadTUS/checksums.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L197)
 - [coreApiWebdavUploadTUS/checksums.feature:240](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L240)
 - [coreApiWebdavUploadTUS/checksums.feature:241](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L241)
 - [coreApiWebdavUploadTUS/checksums.feature:242](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L242)
 - [coreApiWebdavUploadTUS/checksums.feature:243](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L243)
-- [coreApiWebdavUploadTUS/checksums.feature:245](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L245)
 - [coreApiWebdavUploadTUS/checksums.feature:244](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L244)
-- [coreApiWebdavUploadTUS/optionsRequest.feature:10](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L10)
-- [coreApiWebdavUploadTUS/optionsRequest.feature:25](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L25)
-- [coreApiWebdavUploadTUS/uploadToShare.feature:226](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L226)
-- [coreApiWebdavUploadTUS/uploadToShare.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L227)
+- [coreApiWebdavUploadTUS/checksums.feature:245](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L245)
 - [coreApiWebdavUploadTUS/uploadToShare.feature:250](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L250)
 - [coreApiWebdavUploadTUS/uploadToShare.feature:251](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L251)
 - [coreApiWebdavUploadTUS/uploadToShare.feature:274](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L274)
 - [coreApiWebdavUploadTUS/uploadToShare.feature:275](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L275)
-- [coreApiWebdavUploadTUS/uploadToShare.feature:317](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L317)
-- [coreApiWebdavUploadTUS/uploadToShare.feature:318](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L318)
 - [coreApiWebdavUploadTUS/uploadToShare.feature:369](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L369)
 - [coreApiWebdavUploadTUS/uploadToShare.feature:370](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L370)
 
-#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012)
-
-- [coreApiWebdavUploadTUS/optionsRequest.feature:40](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L40)
-- [coreApiWebdavUploadTUS/optionsRequest.feature:55](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L55)
-
 #### [Renaming resource to banned name is allowed in spaces webdav](https://github.com/owncloud/ocis/issues/3099)
 
 - [coreApiWebdavMove2/moveFile.feature:143](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature#L143)

tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md

@@ -124,17 +124,14 @@ The expected failures in this file are from features in the owncloud/ocis repo.
 - [apiLocks/unlockFiles.feature:231](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L231)
 - [apiLocks/unlockFiles.feature:232](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L232)
 
-#### [Trying to upload to a locked file gives 500](https://github.com/owncloud/ocis/issues/7638)
+#### [Folders can be locked and locking works partially](https://github.com/owncloud/ocis/issues/7641)
 
 - [apiLocks/lockFiles.feature:445](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L445)
 - [apiLocks/lockFiles.feature:446](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L446)
 - [apiLocks/lockFiles.feature:447](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L447)
 - [apiLocks/lockFiles.feature:448](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L448)
 - [apiLocks/lockFiles.feature:449](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L449)
 - [apiLocks/lockFiles.feature:450](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L450)
-
-#### [Folders can be locked and locking works partially](https://github.com/owncloud/ocis/issues/7641)
-
 - [apiLocks/lockFiles.feature:419](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L419)
 - [apiLocks/lockFiles.feature:420](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L420)
 - [apiLocks/lockFiles.feature:421](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/lockFiles.feature#L421)
@@ -248,12 +245,12 @@ The expected failures in this file are from features in the owncloud/ocis repo.
 - [apiSpacesShares/moveSpaces.feature:416](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/moveSpaces.feature#L416)
 - [apiSpacesDavOperation/moveByFileId.feature:86](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L86)
 - [apiSpacesDavOperation/moveByFileId.feature:87](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L87)
-- [apiSpacesDavOperation/moveByFileId.feature:210](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L210)
 - [apiSpacesDavOperation/moveByFileId.feature:205](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L205)
 - [apiSpacesDavOperation/moveByFileId.feature:206](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L206)
 - [apiSpacesDavOperation/moveByFileId.feature:207](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L207)
 - [apiSpacesDavOperation/moveByFileId.feature:208](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L208)
 - [apiSpacesDavOperation/moveByFileId.feature:209](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L209)
+- [apiSpacesDavOperation/moveByFileId.feature:210](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L210)
 - [apiSpacesDavOperation/moveByFileId.feature:492](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L492)
 - [apiSpacesDavOperation/moveByFileId.feature:493](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L493)
 

tests/acceptance/features/apiLocks/lockFiles.feature

@@ -163,7 +163,7 @@ Feature: lock files
       | lockscope | exclusive |
     Then the HTTP status code should be "403"
 
-
+  @issue-7599
   Scenario Outline: lock a file in the shares
     Given using <dav-path-version> DAV path
     And user "Alice" has uploaded a file inside space "Alice Hansen" with content "some content" to "textfile.txt"
@@ -518,7 +518,7 @@ Feature: lock files
       | spaces           | shared     |
       | spaces           | exclusive  |
 
-
+  @issue-7790
   Scenario Outline: lock a file shared by a link as anonymous user with edit permission
     Given using <dav-path-version> DAV path
     And using SharingNG
@@ -542,7 +542,7 @@ Feature: lock files
       | spaces           | shared     |
       | spaces           | exclusive  |
 
-
+  @issue-7790
   Scenario Outline: try to lock a file shared by a link as anonymous user with read permission
     Given using <dav-path-version> DAV path
     And using SharingNG

tests/acceptance/features/apiLocks/unlockFiles.feature

@@ -119,7 +119,7 @@ Feature: unlock locked items
       | spaces           | shared     |
       | spaces           | exclusive  |
 
-
+  @issue-7767
   Scenario Outline: trying to unlock a file inside the shared folder that has been locked by the file owner
     Given user "Brian" has been created with default attributes and without skeleton files
     And using <dav-path-version> DAV path

tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature

@@ -218,7 +218,7 @@ Feature: upload resources on share using TUS protocol
       #    L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
       | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
       | Tus-Resumable   | 1.0.0                                 |
-    And user "Alice" has uploaded file with checksum "SHA1 8cb2237d069ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API
+    And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API
     When user "Brian" downloads the file "/FOLDER/textFile.txt" of the space "Shares" using the WebDAV API
     Then the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
 
@@ -270,14 +270,14 @@ Feature: upload resources on share using TUS protocol
       | permissionsRole | Editor   |
     And user "Brian" has a share "FOLDER" synced
     When user "Brian" creates a new TUS resource for the space "Shares" with content "" using the WebDAV API with these headers:
-      | Upload-Length   | 16                                    |
+      | Upload-Length   | 5                                     |
       #    L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
       | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
       | Tus-Resumable   | 1.0.0                                 |
-    And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "uploaded content" via TUS inside of the space "Shares" using the WebDAV API
+    And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Shares" using the WebDAV API
     Then for user "Alice" folder "FOLDER" of the space "Personal" should contain these entries:
       | textFile.txt |
-    And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "uploaded content"
+    And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "12345"
 
   @issue-1755
   Scenario: sharee uploads a file to a received share folder with wrong checksum should not work
@@ -290,11 +290,11 @@ Feature: upload resources on share using TUS protocol
       | permissionsRole | Editor   |
     And user "Brian" has a share "FOLDER" synced
     When user "Brian" creates a new TUS resource for the space "Shares" with content "" using the WebDAV API with these headers:
-      | Upload-Length   | 16                                    |
+      | Upload-Length   | 5                                     |
       #    L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
       | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
       | Tus-Resumable   | 1.0.0                                 |
-    And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e8c" to the last created TUS Location with offset "0" and content "uploaded content" via TUS inside of the space "Shares" using the WebDAV API
+    And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12346" via TUS inside of the space "Shares" using the WebDAV API
     Then the HTTP status code should be "460"
     And for user "Alice" folder "FOLDER" of the space "Personal" should not contain these entries:
       | textFile.txt |
@@ -314,7 +314,7 @@ Feature: upload resources on share using TUS protocol
       #    L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
       | Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
       | Tus-Resumable   | 1.0.0                                 |
-    When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513954" to the last created TUS Location with offset "0" and content "uploaded content" via TUS inside of the space "Personal" using the WebDAV API
+    When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12346" via TUS inside of the space "Personal" using the WebDAV API
     Then the HTTP status code should be "460"
     And for user "Alice" folder "FOLDER" of the space "Personal" should not contain these entries:
       | textFile.txt |

tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature

@@ -59,15 +59,15 @@ Feature: checksums
       | new              |
       | spaces           |
 
-
+  @issue-1755
   Scenario Outline: uploading a file with incorrect checksum should not work
     Given using <dav-path-version> DAV path
     And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
       | Upload-Length   | 5                         |
       #    dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
       | Upload-Metadata | filename dGV4dEZpbGUudHh0 |
     When user "Alice" uploads file with checksum "<checksum>" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
-    Then the HTTP status code should be "406"
+    Then the HTTP status code should be "460"
     And as "Alice" file "textFile.txt" should not exist
     Examples:
       | dav-path-version | checksum                                      |
@@ -131,16 +131,16 @@ Feature: checksums
       | new              |
       | spaces           |
 
-
+  @issue-1755
   Scenario Outline: uploading second chunk of file with incorrect checksum should not work
     Given using <dav-path-version> DAV path
     And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
       | Upload-Length   | 10                        |
       #    dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
       | Upload-Metadata | filename dGV4dEZpbGUudHh0 |
-    When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546799" using the TUS protocol on the WebDAV API
-    And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 781e5e245d69b566979b86e28d23f2c7" using the TUS protocol on the WebDAV API
-    Then the HTTP status code should be "409"
+    And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
+    When user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 781e5e245d69b566979b86e28d23f2c7" using the TUS protocol on the WebDAV API
+    Then the HTTP status code should be "460"
     And as "Alice" file "textFile.txt" should not exist
     Examples:
       | dav-path-version |
@@ -173,7 +173,7 @@ Feature: checksums
       | spaces           | MD5 5d41402abc4b2a76b9719d911017c592          |
       | spaces           | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
 
-
+  @issue-1755
   Scenario Outline: uploading a file with correct checksum and overwriting an existing file with invalid checksum should not work
     Given using <dav-path-version> DAV path
     And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
@@ -185,7 +185,7 @@ Feature: checksums
     When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<checksum>" using the TUS protocol on the WebDAV API with these headers:
       | Upload-Length   | 5                         |
       | Upload-Metadata | filename dGV4dEZpbGUudHh0 |
-    Then the HTTP status code should be "406"
+    Then the HTTP status code should be "460"
     And the content of file "/textFile.txt" for user "Alice" should be "0123456789"
     Examples:
       | dav-path-version | checksum                                      |
@@ -221,7 +221,7 @@ Feature: checksums
       | spaces           | MD5 5d41402abc4b2a76b9719d911017c592          |
       | spaces           | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
 
-
+  @issue-1755
   Scenario Outline: overwriting an existing file with new data and invalid checksum should not work
     Given using <dav-path-version> DAV path
     And user "Alice" has created a new TUS resource on the WebDAV API with these headers: