test(coreApiWebdavOperations): download a file with a literal "%" via its oc:downloadURL#3079
Open
michaelstingl wants to merge 1 commit into
Open
Conversation
… its oc:downloadURL A file whose name contains a literal "%" 404s on download because the server-built oc:downloadURL did not percent-encode the path (opencloud-eu#2852, fixed in reva by opencloud-eu/reva#653). Add a scenario mirroring the web client download flow: read the oc:downloadURL from PROPFIND and GET it as-is (the signature in the URL authenticates it), asserting 200 and the content. The new step "user X downloads the P file via its oc:downloadURL" lives in WebDavPropertiesContext; a regex annotation avoids the ":" in oc:downloadURL colliding with the turnip :placeholder syntax. Verified red->green on posix and decomposed: red on an opencloud built on a reva with the fix reverted (the download 404s), green on the shipped reva. opencloud-eu#2852
Up to standards ✅🟢 Issues
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds one scenario to
tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature: a file whose name contains a literal%downloads via itsoc:downloadURL, returning200and the content.It mirrors the web client's download flow: read the server-built
oc:downloadURLfrom a PROPFIND and GET it as-is (the signature in the URL authenticates the request, so no credentials are sent). A plain WebDAVdownloads filestep would not cover this, because it builds and encodes the request path itself, whereas the bug is in the server-generatedoc:downloadURL.One new step-def in
WebDavPropertiesContext,user "X" downloads the "P" file via its oc:downloadURL, reuses the existing PROPFIND helper andHttpRequestHelper::get. It uses a regex annotation because the:inoc:downloadURLcollides with the turnip:placeholdersyntax.Related Issue
Locks the behaviour from #2852 (closed) in the acceptance suite. The fix itself is in reva:
Motivation and Context
A name with a literal
%(for examplefirstword%20secondword.txt) 404'd on download because theoc:downloadURLdid not percent-encode the path, so a URL parser collapsed the%20back to a space. The reva fix corrected it; this pins the round-trip at the product boundary so a regression fails the suite.How Has This Been Tested?
Locally, the feature against a running server, on two builds and both storages:
downloadFile.featurepasses on posix and decomposed (81/81), the new scenario green on old/new/spaces.404(the reporter's exact symptom), on posix.Screenshots (if appropriate):
Types of changes
Checklist:
🤖 drafted with Claude Code, reviewed before submitting.