Non-canonical S3BotoStorage sends unicode content-type through to boto, which ends up improperly escaped

[admin-ns]

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 boto/boto#1669

Current version of django-storages doesn't suffer from this issue, so I assume that implementing #21 would fix this.

[gtaylor]

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.

[admin-ns]

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 [email protected]:

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//issues/25#issuecomment-27137479
.

[admin-ns]

Okay I can confirm that the storages branch doesn't appear to suffer from this particular issue.