mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-07-30 01:08:50 -04:00
76ffc82bba
* test(coreApiWebdavUploadTUS): assert etag and permissions on the finalizing TUS chunk The chunked TUS finalize returns OC-ETag, ETag and OC-Perm since https://github.com/opencloud-eu/reva/pull/718, so a client no longer needs a follow-up PROPFIND for the new etag and permissions. Add a scenario asserting these headers on the finalizing chunk, reusing existing step definitions (the etag is a dynamic quoted hash, hence the header-regex assertion). Verified locally red->green: red on stock (headers absent), green on an opencloud built on a reva carrying that change, on posix and decomposed. https://github.com/opencloud-eu/opencloud/issues/2409 * test(coreApiWebdavUploadTUS): assert exact OC-Perm and tighten etag regex --------- Co-authored-by: v.scharf <v.scharf@opencloud.eu>
115 lines
5.4 KiB
Gherkin
115 lines
5.4 KiB
Gherkin
Feature: low level tests for upload of chunks
|
|
As a user
|
|
I want to be able to upload resources in chunks
|
|
So that I can manage my resources
|
|
|
|
Background:
|
|
Given user "Alice" has been created with default attributes
|
|
|
|
|
|
Scenario Outline: upload a chunk twice
|
|
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 |
|
|
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
|
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
|
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "000" using the WebDAV API
|
|
Then the HTTP status code should be "409"
|
|
And as "Alice" file "file.txt" should not exist
|
|
Examples:
|
|
| dav-path-version |
|
|
| old |
|
|
| new |
|
|
| spaces |
|
|
|
|
|
|
Scenario Outline: finalize file upload after uploading a chunk twice
|
|
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 |
|
|
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
|
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
|
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "000" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API
|
|
Then the HTTP status code should be "204"
|
|
And the content of file "/file.txt" for user "Alice" should be "1234567890"
|
|
Examples:
|
|
| dav-path-version |
|
|
| old |
|
|
| new |
|
|
| spaces |
|
|
|
|
|
|
Scenario Outline: send last chunk twice
|
|
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 |
|
|
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
|
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
|
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "0000000" with retry on offset mismatch using the WebDAV API
|
|
Then the HTTP status code should be "404"
|
|
And the content of file "/file.txt" for user "Alice" should be "1234567890"
|
|
Examples:
|
|
| dav-path-version |
|
|
| old |
|
|
| new |
|
|
| spaces |
|
|
|
|
|
|
Scenario Outline: send last chunk with mismatch offset
|
|
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 |
|
|
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
|
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
|
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "2" and data "34567890" using the WebDAV API
|
|
Then the HTTP status code should be "409"
|
|
Examples:
|
|
| dav-path-version |
|
|
| old |
|
|
| new |
|
|
| spaces |
|
|
|
|
|
|
Scenario Outline: start with uploading not at the beginning of the file
|
|
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 |
|
|
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
|
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
|
When user "Alice" sends a chunk to the last created TUS Location with offset "1" and data "123" using the WebDAV API
|
|
Then the HTTP status code should be "409"
|
|
And as "Alice" file "file.txt" should not exist
|
|
Examples:
|
|
| dav-path-version |
|
|
| old |
|
|
| new |
|
|
| spaces |
|
|
|
|
@issue-2409
|
|
Scenario Outline: finalize a chunked upload and get the etag and permissions
|
|
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 |
|
|
# ZmlsZS50eHQ= is the base64 encode of file.txt
|
|
| Upload-Metadata | filename ZmlsZS50eHQ= |
|
|
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API
|
|
And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API
|
|
Then the HTTP status code should be "204"
|
|
And the following headers should be set
|
|
| header | value |
|
|
| OC-Perm | RDNVWZP |
|
|
And the following headers should match these regular expressions
|
|
| OC-ETag | /^"[a-f0-9:.]{1,32}"$/ |
|
|
| ETag | /^"[a-f0-9:.]{1,32}"$/ |
|
|
Examples:
|
|
| dav-path-version |
|
|
| old |
|
|
| new |
|
|
| spaces |
|