Adds SWIFT_CONTENT_LENGTH_FROM_FD

[pomegranited]

Adds SWIFT_CONTENT_LENGTH_FROM_FD with default True, which preserves the current behaviour by inferring the content_length header from the Django File object's size attribute when saving the object.

Using SWIFT_CONTENT_LENGTH_FROM_FD: False will send content_length = None, allowing the SWIFT backend to determine the content length using the content read.

This is a workaround for a bug we encountered with Django ContentFile objects (prior to Django2) which can mis-report their size if changed after initialisation. See added test_no_content_length_from_fd() for example.

Reviewers

• [x] @clemente

[codecov-io]

Codecov Report

Merging #100 into master will increase coverage by 0.02%. The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #100      +/-   ##
==========================================
+ Coverage   97.89%   97.92%   +0.02%     
==========================================
  Files           1        1              
  Lines         238      241       +3     
==========================================
+ Hits          233      236       +3     
  Misses          5        5

Impacted Files	Coverage Δ
swift/storage.py	97.92% <100%> (+0.02%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 27d34cf...4d560fb. Read the comment docs.

[clemente]

Another option would be to track who is doing .write() and make that method update the .size attribute too, to keep it correct. Then we could always send it. But it would involve changing every possible user. Because sending the content length isn't required by SWIFT, better not to send it.

• [X] I tested this: I ran the tests in local, and checked that it sends None when setting the new parameter, and 0 when not setting it (i.e. default). I also tested the difference in a sandbox (Open edX project), and checked that uploaded CSV files have content, whereas in another server without this patch, the files were empty
• [X] I read through the code
• [X] I checked for accessibility issues
• [ ] Includes documentation: not yet, @pomegranited could you add some small comment to the code itself, or to the README („troubleshooting“) that says that if you use ContentFile and get empty uploads you must use this new parameter?

With that documentation, :+1:

[pomegranited]

Hi @dennisv @einarf -- would you be willing to review this PR? Thank you!

[pomegranited]

Thank you @dennisv ! Could we also get 1.2.19 pushed to pypi?