We URI encode all keys because they may contain characters outside the URI spec and also include the separator / character replacing with %2F. Any S3 interoperable provider should always URI decode request URIs. Please open an issue with Ceph Support.
I'm kinda skeptical about that. Since it's the directory separator, and S3 is a flat structure, slashes are just assumed to be slashes. (ie, since there is no concept of a directory, a slash in a key name will always be just that, both a slash in the keyname as well as a fake 'path separator'. There's no case where you'd want an encoded forward-slash)
Its specifically included as 'safe' to include in key names. In fact, forward slash is specifically NOT included in the list of characters that you need to URL-Encode when passing to the S3 service, in this document:
This is using a non-https Ceph S3 (Radosgw) server.
According to tcpdump, Cybderduck is encoding the slash in the key-name:
The bucket index looks like:
The forward slash in the key name should not be encoded by cyberduck before it tries to download it.
I have not tested this with Amazon S3, so i'm not sure if this only affects Ceph/insecure s3.
The text was updated successfully, but these errors were encountered: