Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stable10] tests async operations #32594

Merged
merged 1 commit into from
Sep 12, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions tests/TestHelpers/HttpRequestHelper.php
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,9 @@ class HttpRequestHelper {
* @param mixed $body
* @param array $config
* @param CookieJar $cookies
* @param boolean $stream
* @param bool $stream Set to true to stream a response rather
* than download it all up-front.
* @param int $timeout
*
* @throws BadResponseException
* @return ResponseInterface
Expand All @@ -56,7 +58,8 @@ public static function sendRequest(
$body = null,
$config = null,
$cookies = null,
$stream = false
$stream = false,
$timeout = 0
) {
$client = new Client();
$options = [];
Expand All @@ -74,7 +77,7 @@ public static function sendRequest(
}
$options['stream'] = $stream;
$options['verify'] = false;

$options['timeout'] = $timeout;
$request = $client->createRequest($method, $url, $options);
if ($headers !== null) {
foreach ($headers as $key => $value) {
Expand Down
10 changes: 8 additions & 2 deletions tests/TestHelpers/WebDavHelper.php
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,9 @@ public static function getFileIdForPath(
* @param string $type of request
* @param string $sourceIpAddress to initiate the request from
* @param string $authType basic|bearer
* @param bool $stream Set to true to stream a response rather
* than download it all up-front.
* @param int $timeout
*
* @return ResponseInterface
*/
Expand All @@ -102,7 +105,9 @@ public static function makeDavRequest(
$davPathVersionToUse = 1,
$type = "files",
$sourceIpAddress = null,
$authType = "basic"
$authType = "basic",
$stream = false,
$timeout = 0
) {
$baseUrl = self::sanitizeUrl($baseUrl, true);
$davPath = self::getDavPath($user, $davPathVersionToUse, $type);
Expand Down Expand Up @@ -138,7 +143,8 @@ public static function makeDavRequest(
}

return HttpRequestHelper::sendRequest(
$fullUrl, $method, $user, $password, $headers, $body, $config
$fullUrl, $method, $user, $password, $headers, $body, $config, null,
$stream, $timeout
);
}

Expand Down
18 changes: 18 additions & 0 deletions tests/acceptance/features/apiCapabilities/capabilities.feature
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,24 @@ Feature: capabilities
| capability | path_to_element | value |
| files_sharing | can_share | 1 |

#feature added in #32414 will be released in 10.0.10
@skipOnOcV10.0.9
Scenario: getting async capabilites when async operations are enabled
Given the administrator has enabled async operations
When the user retrieves the capabilities using the capabilities API
Then the capabilities should contain
| capability | path_to_element | value |
| async | | 1.0 |

#feature added in #32414 will be released in 10.0.10
@skipOnOcV10.0.9
Scenario: getting async capabilites when async operations are disabled
Given the administrator has disabled async operations
When the user retrieves the capabilities using the capabilities API
Then the capabilities should contain
| capability | path_to_element | value |
| async | | EMPTY |

Scenario: Changing public upload
Given parameter "shareapi_allow_public_upload" of app "core" has been set to "no"
When the user retrieves the capabilities using the capabilities API
Expand Down
48 changes: 48 additions & 0 deletions tests/acceptance/features/apiMain/checksums.feature
Original file line number Diff line number Diff line change
Expand Up @@ -142,6 +142,54 @@ Feature: checksums
And user "user0" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API
Then the HTTP status code should be "400"

Scenario: Upload new dav chunked file using async MOVE where checksum matches
Given using new DAV path
And the administrator has enabled async operations
When user "user0" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "user0" should be "BBBBBCCCCC"

Scenario: Upload new dav chunked file using async MOVE where checksum does not matches
Given using new DAV path
And the administrator has enabled async operations
When user "user0" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^error$/ |
| errorCode | /^400$/ |
| errorMessage | /^The computed checksum does not match the one received from the client.$/ |
And user "user0" should not see the following elements
| /myChunkedFile.txt |

Scenario: Upload new dav chunked file using async MOVE where checksum does not matches - retry with correct checksum
Given using new DAV path
And the administrator has enabled async operations
When user "user0" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API
And user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "user0" should be "BBBBBCCCCC"

Scenario Outline: Upload a file where checksum does not match
Given using <dav_version> DAV path
And file "/chksumtst.txt" has been deleted for user "user0"
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,165 @@
@api @TestAlsoOnExternalUserBackend
Feature: upload file using new chunking
As a user
I want to be able to upload "large" files in chunks asynchronously
So that I do not have to wait for the long MOVE operation on assembly to finish

Background:
Given using new DAV path
And user "user0" has been created
And the owncloud log level has been set to debug
And the owncloud log has been cleared
And the administrator has enabled async operations

Scenario: Upload chunked file ordered asc using async MOVE
When user "user0" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |

Scenario: Upload chunked file ordered desc using async MOVE
When user "user0" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| 3 | CCCCC |
| 2 | BBBBB |
| 1 | AAAAA |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |

Scenario: Upload chunked file in random order using async MOVE
When user "user0" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| 2 | BBBBB |
| 3 | CCCCC |
| 1 | AAAAA |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/myChunkedFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |

Scenario: Upload chunked file overwriting existing file using async MOVE
Given user "user0" has copied file "/textfile0.txt" to "/existingFile.txt"
When user "user0" uploads the following chunks asynchronously to "/existingFile.txt" with new chunking and using the WebDAV API
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And the content of file "/existingFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |

Scenario: New chunked upload MOVE using old DAV path should fail
Given user "user0" has created a new chunking upload with id "chunking-42"
And user "user0" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42"
And user "user0" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42"
And user "user0" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42"
When using old DAV path
And user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" using the WebDAV API
Then the HTTP status code should be "404"

Scenario: Upload file via new chunking endpoint with wrong size header using async MOVE
Given user "user0" has created a new chunking upload with id "chunking-42"
And user "user0" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42"
And user "user0" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42"
And user "user0" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42"
When user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 5 using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^error$/ |
| errorCode | /^400$/ |
| errorMessage | /^Chunks on server do not sum up to 5 but to 15$/ |

Scenario: Upload file via new chunking endpoint with correct size header using async MOVE
Given user "user0" has created a new chunking upload with id "chunking-42"
And user "user0" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42"
And user "user0" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42"
And user "user0" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42"
When user "user0" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 15 using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And as "user0" the file "/myChunkedFile.txt" should exist
And the content of file "/myChunkedFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |

Scenario Outline: Upload files with difficult names using new chunking and async MOVE
When user "user0" creates a new chunking upload with id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
And user "user0" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
And user "user0" moves new chunk file with id "chunking-42" asynchronously to "/<file-name>" using the WebDAV API
Then the HTTP status code should be "202"
And the following headers should match these regular expressions
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/user0\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
And the oc job status values of last request for user "user0" should match these regular expressions
| status | /^finished$/ |
| fileId | /^[0-9a-z]{20,}$/ |
And as "user0" the file "/<file-name>" should exist
And the content of file "/<file-name>" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Examples:
| file-name |
| &#? |
| TIÄFÜ |

Scenario: disabled async operations leads to original behavior
Given the administrator has disabled async operations
When user "user0" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "201"
And the following headers should not be set
| OC-JobStatus-Location |
And the content of file "/myChunkedFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"

Scenario: enabling async operations does no difference to normal MOVE - Upload chunked file
When user "user0" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "201"
And the following headers should not be set
| OC-JobStatus-Location |
And as "user0" the file "/myChunkedFile.txt" should exist
And the content of file "/myChunkedFile.txt" for user "user0" should be "AAAAABBBBBCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |
Loading