Allow encoding to be specified with S3 storage class #585
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using local file storage with Shrine, a call to
#read
will acceptencoding: ...
in the same way as one might expect for a regular IO object. This is quite important when dealing with input data for things like CSV which might come from all manner of sources, including correctly-encoded UTF-8 with or without BOM, ISO8859-1 or (quite often) Windows CP1252.In our application, we used this to figure out the encoding and decode the CSV accordingly, but while it works for local development where file storage is convenient for most engineers, it didn't work in deployment since the S3 storage class didn't understand that option and just passed it through to the AWS SDK, which understandably complained.
This PR fixes that in a backwards-compatible way by accepting a with-nil-default encoding option and passing it to the
Down::ChunkedIO
constructor. The updated tests pass with the patch present, else fail with:That's not the end of the story, unfortunately! When Shrine is actually (out of tests) driving the
Down::ChunkedIO
object, it calls#read
on the instance and passes a buffer length. For some reason, if and only if a buffer length is given, Down currently ignores the encoding that it's been given. This is addressed by janko/down#74, which will hopefully be merged soon.In the mean time, this PR for Shrine is harmless and beneficial if either using a monkey-patched Down gem (as we currently are, as well as monkey patched Shrine!) or using a future Down gem release with the above PR merged.