Percent decode the list files when parsing response#93
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #93 +/- ##
==========================================
+ Coverage 90.23% 90.31% +0.07%
==========================================
Files 29 29
Lines 1372 1383 +11
==========================================
+ Hits 1238 1249 +11
Misses 134 134 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
paolobarbolini
left a comment
There was a problem hiding this comment.
Thanks for the PR. I had completely missed the fact they are encoding the keys.
| // #[serde(rename = "EncodingType")] | ||
| // encoding_type: String, | ||
| #[serde(rename = "EncodingType")] | ||
| encoding_type: String, |
There was a problem hiding this comment.
I'm wandering whether this should be an enum or not
There was a problem hiding this comment.
Like an Option<String>?
Since there is an official S3 specification, as far as I know, I have no idea.
What I can say is that DO, minio, and was all return the encoding_type set to url. But maybe some other providers don't.
I would say we keep it like that until someone gives us an implementation that doesn't work like that personally 😅
|
Hey, sorry I was on holiday last week. |
Hello, while trying out the
ListObjectsV2::parse_responsecommand I noticed that we were not percent decoding the keys as documented here: https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html#API_ListObjectsV2_RequestSyntaxI had no issue with
minioas I don't use any strange characters. But the Digital Ocean S3 implementation does percent-encode the/character, which completely broke my code.I updated my lib, but I think it should be handled by rusty_s3 directly, personally 🤔
What do you think?