Cannot download files that have "%20" in their filename.

[MarkusF42]

Describe the bug

For example, the file is named firstword%20secondword.pdf

An error like the following is shown in the Docker logs when someone tries to download such a file from their personal storage or from a space:

INF access-log bytes=0 duration=19.142178 line=github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/accesslog.go:34 method=GET path="/remote.php/dav/spaces/<uuid>/firstword secondword.pdf" proto=HTTP/1.0 remote-addr=x.x.x.x request-id=edf75f1490de/kpX31ict7d-160173 service=proxy status=404 traceid=042a69c9d2fa0deba4450b9c1e70a929

However, if the file is shared with someone else, the other person is able to download it.

It seems to me that downloads from personal or shared space storage decode '%20' as a space character, while downloads of shared files do not.

Steps to reproduce

1. Create a file with '%20' in its name in a personal storage or space
2. Try to download it via the Download button in the web UI

Expected behavior

The %20 should not be parsed as a space character and the user is able to download it.

Actual behavior

The user gets a 404 error in web UI, when he tries to download a file with '%20' in its name.

Setup

OpenCloud 4.0.7 via docker compose

[michaelstingl]

Root cause: PROPFIND builds oc:downloadURL with url.JoinPath, which unescapes its input, while the sibling href uses net.EncodePath, which does not. For a name that contains a literal %, the two results differ.

BASE="https://<host>/remote.php/dav/spaces/<spaceID>"
AUTH="-u USER:<app-token>"

# create a file whose stored name literally contains "%20" (send %2520, server decodes once)
curl -s $AUTH -T file.pdf "$BASE/firstword%2520secondword.pdf"

# request its href + oc:downloadURL
curl -s $AUTH -X PROPFIND -H 'Depth: 1' "$BASE/" \
  --data '<?xml version="1.0"?><d:propfind xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns"><d:prop><oc:downloadURL/></d:prop></d:propfind>'

<d:href>          …/firstword%2520secondword.pdf   <!-- correct: "%" -> "%25" -->
<oc:downloadURL>  …/firstword%20secondword.pdf      <!-- under-encoded -->

The web client downloads through oc:downloadURL. The browser therefore sends %20, the proxy decodes it to a space, and the storage lookup for firstword secondword.pdf returns 404 (the path shown in the access log):

GET …/firstword%20secondword.pdf     -> 404   (decoded to a space; no such file)
GET …/firstword%2520secondword.pdf   -> 200   (correctly encoded; the file is fine)

A public link still downloads the file: that path resolves the file by its share token and returns no oc:downloadURL, so the filename in the URL does not affect the lookup. A file shared with another user behaves the same way as the owner's view: the recipient receives the same under-encoded oc:downloadURL and also gets 404 (verified on a recipient account).

Where this happens in reva (vendored). PROPFIND builds two URLs for the same name; only the href is encoded correctly:

href            propfind.go:1086   net.EncodePath(path)         "%" -> "%25"   ok
oc:downloadURL  propfind.go:1740   url.JoinPath("/", parts...)  unescapes input, "%" dropped

Downloading that under-encoded URL, one request top to bottom:

proxy access-log       r.URL.Path = ".../firstword secondword.pdf"   (%20 decoded to a space)
  ocdav GET handler    looks up the decoded path
    gateway Stat
      storage Stat      not found: <spaceID>/firstword secondword.pdf   <- origin

back up: storage NotFound -> ocdav errors -> 404

url.JoinPath is used here to keep a literal # working (see opencloud-eu/reva#415); because it unescapes its input, a literal % does not survive. net.EncodePath, the encoder the href already uses, escapes both # (to %23) and % (to %25), so it covers both cases. The GET handler and the proxy decode the URL they receive correctly; only the URL this property emits needs to change.

_{🤖 drafted with Claude Code, reviewed before submitting.}