You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: