Open rbroemeling opened 12 years ago
This is possibly related to https://github.com/rightscale/right_aws/issues/109
Indeed. The problem was changing CGI.escape -> URI.escape in this commit:
https://github.com/rbroemeling/right_aws/commit/78d63f59c913546f371d5aa4eae1708267b25774
URI.escape does not properly escape + symbols:
irb(main):002:0> URI.escape("document_versions/123456/foo + bar.pdf") => "document_versions/123456/foo%20+%20bar.pdf"
Suggest that the code in https://github.com/rightscale/right_aws/commit/78d63f59c913546f371d5aa4eae1708267b25774 be changed back to CGI::escape, and then .gsub('+', '%20') be called on the result. This results in an actually correct encoding, as far as I can tell:
irb(main):015:0> CGI.escape('foo + bar.pdf').gsub('+', '%20') => "foo%20%2B%20bar.pdf"
I have opened a pull request for this change:
I've confirmed that the code in pull #115 fixes all permutations of spaces and + that we can think of.
Hi
Could you plz try the "development" (not "master") branch and see if the issue is fixed there or not.
Thank you!
Hi,
I can confirm that the current development branch of right_aws fixes the issue and passes all known test cases that we have tried (i.e. spaces, plus signs, and other 'special' character tests).
When will we see the code move into master/into a release?
Thanks!
A get_link call on a file that has a "+" in it's name does not get URL encoded correctly, and thus the actual fetch results in a NoSuchKey error from Amazon S3.
i.e. given a key called "document_versions/123456/foo + bar.pdf"
this SHOULD ENCODE TO "document_versions/123456/foo%20%2B%20bar.pdf"
instead, it encodes to "document_versions/123456/foo%20+%20bar.pdf"
which in turn actually decodes to: "document_versions/123456/foo bar.pdf" (the "+" is replaced by a space).