Open bensu opened 9 years ago
@bensu Two small things:
git commit --amend
and force push if you like.)@martinklepsch sure!
@bensu Do I understand correctly that you'll need to provide your own s3-sign
ring handler to supply the key function? Maybe we want to remove the s3-sign
route completely and just provide an example in the readme?
In any case adding a usage example would be nice I think.
Sorry for the delayed reply :)
Hey @martinklepsch & @bensu ,
I took some time and worked to get this patch up to date with master. I also removed the s3-sign route and updated the readme with an example of using a custom key. Let me know what you think, please at https://github.com/martinklepsch/s3-beam/pull/16 . Cheers!
This is a conflict free version of #6 . For convenience:
Users can now provide a :key-fn to the server handler which given file-name and mime-type will determine the key to use for the S3 file.
Caveat: if the client provides a file my-file.txt and the :key-fn generates a random number as a key (i.e. 12314345), the file location in S3 is given by 12314345, which is what was passed back in the s3-pipe uploaded channel. The file location is no longer sufficient for the client to know which file was successfully uploaded (in case of parallel uploads).
My (non-backwards-compatible) proposal is to put in the uploaded channel all information relevant to the client: both the file object that was uploaded and the response from S3 which contains the :key, :location, :bucket, and :etag.