-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keys for non-url friendly filenames are getting encoded multiple times. #113
Comments
I'm seeing the same issue as well. |
Same here. From what I could gather, this happens in carrierwave_direct/uploader.rb,
if the url contains %20 (encoded spaces) when you encode again, it'll encode the % to %25, resulting in the final %2520. If I replace the code above with
it seems to work, decoding the %20 to regular spaces again. |
+1 on this issue. Sadly, the change proposed by @JohnBernas is not working for me. |
I changed the line mentioned above in self.key = URI.decode(URI.parse(URI.encode(url, " []+()")).path[1 .. -1]) # explicitly set key That worked for me. |
@remino Would you mind submitting a pull request with your change? |
Sure. Just sent a pull request: #124. |
This should be fixed on master with #155 |
Hi, I posted my problem on SO but I think it would be better served here. Original question can be seen here:
http://stackoverflow.com/questions/19645506/how-can-i-force-url-friendly-filenames-when-using-carrierwavedirect-in-ruby-on-r
I have users uploading files with non url friendly names. Mainly, filenames that include spaces. I have an admin area where moderators can approve a photo. In the admin tool the image_url works just fine. The image path is url escaped with %20 in place of the spaces. The trouble is when the moderator approves the photo I make a simple asynchronous JSON POST request which in simply does this:
As a result of that call to update_attribute I see a SQL statement like this:
Now the image path is broken as the database is storing a twice encoded string when the internal string shouldn't be encoded at all. At least, I don't think it should. I do not know why the image attribute is also being updated during this call. Any idea why this is and/or is there a better way to be managing non url-friendly filenames from user generated content?
The text was updated successfully, but these errors were encountered: