supabase / supabase-flutter / 28437115472

86%

push

github

fix(storage): percent-encode object paths in request URLs (#1479)

## What

Object keys are now percent-encoded when building Storage request URLs,
so keys containing characters that are reserved in a URL (like `?`, a
space, `:` or `+`) address the correct object instead of corrupting the
URL.

## Why

`_getFinalPath` built the URL path by raw interpolation:

```dart
String _getFinalPath(String path) {
  return '$bucketId/$path';
}
```

The result is passed to `Uri.parse('$url/object/$finalPath')` (and the
`render/...` / `object/sign/...` variants). When the key contains a
reserved character it breaks the URL, most visibly in `download`:

```dart
var fetchUrl = Uri.parse('$url/$renderPath/$finalPath');
fetchUrl = fetchUrl.replace(queryParameters: query);
```

`download('a?b.png')` parses the `?` as the start of the query string,
so `.replace(queryParameters: ...)` discards everything after it and the
SDK silently fetches the wrong object. A space can make `Uri.parse`
throw.

The fix percent-encodes each segment using RFC 3986 path-segment rules:

```dart
final encodedPath = Uri(pathSegments: path.split('/')).path;
return '$bucketId/$encodedPath';
```

This encodes the characters that actually corrupt a URL (`?`, `#`, `%`,
spaces) while leaving characters that are already valid in a path
segment untouched, so existing keys (for example ISO-8601 timestamps
containing `:`) produce byte-identical URLs.

## This matches what the storage server does

The storage server percent-decodes the path segments back to the literal
key, so an encoded URL and the literal object key resolve to the same
object. This was verified end to end against a local stack (upload, then
download and list): keys containing `?`, a space, `:`, `+`, `,`, `@`,
`=`, `&` and `;` round-trip correctly and are stored under their decoded
names.

Note that `#` and `%` are rejected by the storage server's own key
validation (`InvalidKey`) regardless of encoding, so this change does
not make tho... (continued)

2 of 2 new or added lines in 1 file covered. (100.0%)

4133 of 4828 relevant lines covered (85.6%)

3.74 hits per line