Open admin-ns opened 11 years ago
I can't remember what shape it's in, but conversion to the standard django-storages is in a branch here: https://github.com/gtaylor/django-athumb/tree/storages
If you wanted to run off of this and let me know how it works for you, maybe we can get it finished up and launched.
TBH, I'm not actually using athumb in my project at the moment, but was inadvertently using the S3BotoStorage import from it instead of the django-storages one (careless IDE auto-import), so I'm probably not a great one to test it out the branch with any degree of thoroughness, although i could certainly check to see if it solves this particular problem. I just switched the import to django-storages and things started working.
On Fri, Oct 25, 2013 at 8:30 PM, Greg Taylor notifications@github.comwrote:
I can't remember what shape it's in, but conversion to the standard django-storages is in a branch here: https://github.com/gtaylor/django-athumb/tree/storages
If you wanted to run off of this and let me know how it works for you, maybe we can get it finished up and launched.
— Reply to this email directly or view it on GitHubhttps://github.com/gtaylor/django-athumb/issues/25#issuecomment-27137479 .
Okay I can confirm that the storages branch doesn't appear to suffer from this particular issue.
Basically, content-type's of files uploaded through django FileFields get improperly escaped by the version of S3BotoStorage in athumb because unicode Content-type headers get sent through boto, which escapes them, which aws doesn't unescape. So you end up with a content-type metadata in aws looking something like
application%2fpdf
. Aside from being a bad content-type in and of itself, this causes Chrome's pdf reader to get hung up.See https://github.com/boto/boto/issues/1669
Current version of django-storages doesn't suffer from this issue, so I assume that implementing #21 would fix this.