1. David Larlet
  2. django-storages
  3. Pull requests

Pull requests

#32 Declined

s3boto gzip fix and associated unit tests.

  1. Ben Timby

A small fix to s3boto backend to fix gzipping.

Two unit tests are also provided. One ensures that .css files are gzipped (when enabled). The other test calls _compress_content() directly and verifies the returned file length is greater than 0. This test would fail without my fix.

Comments (11)

  1. Ben Timby author

    Ian, actually now that I look, I see there are some tests for s3boto (storages/tests/s3boto.py). If you like, I can provide a simple regression test there...

    The scenario that caused problems for me is that I am using storages to manage files in S3, which I serve via CloudFront. These files are a lot of .css and .js files, which will gzip when settings.AWS_IS_GZIPPED = True. I am using gzip, as that helps load times for my app.

    Without my change, .css and .js files are all 0 length. With this change, they upload properly (and are smaller than original file). Other file types like .png are never 0 length. That is what helped me zero in on the gzip function quickly.

    I could package that up into a couple test cases.

  2. Ian Lewis


    unittest.skipIf was added in Python 2.7. I'd like to support all python versions Django supports for unittests as well as the main code so can you fix that please? We need to support at least Python 2.5 (preferably 2.4 for older versions of Django)

  3. Deepak Prakash

    Okay, this is a great fix. I was planning to use the AWS gzip option in exactly the same manner that Ben Timby described and came across this issue. This would enable seamless gzipping and upload to S3 with "collectstatic", without introducing yet another dependency on "django-storages" and the like.

    Please pull this into the main repository as soon as possible, provided everything is fine. Thanks!