aws-beam/aws-elixir

`AWS.S3.put_object` doesn't work with mp3 file

Closed this issue · 5 comments

I've tried to put mp3 file with code as shown in the example, so something like

iex> client = AWS.Client.create(..., ..., ...)
iex> file =  File.read!("path_to_mp3_file")
iex> md5 = :crypto.hash(:md5, file) |> Base.encode64()
iex> AWS.S3.put_object(AWSUtils.client(), bucket, path, %{
      "Body" => file,
      "ContentMD5" => md5
    })

The response was with status code 200:

%{
   body: "",
   headers: [...],
   status_code: 200
 }}

However, when I reach the expected URL I got an error from S3

This page contains the following errors:
error on line 1 at column 1: Document is empty
error on line 1 at column 1: Encoding error

P.S. I tried to use ExAws.S3.put_object and everything worked fine.

Hi @Victoria91 👋

This is strange 🤔 It shouldn't fail based on file type.
I want to ask you to try two things:

  • try to use the version from the master branch instead of the one from Hex.pm (a new version will arrive soon there).
  • try to download the file using AWS.S3 after you upload it.

I suspect if there is a problem it is related with something in the access of the file.

Hi, thanks for the reply!

try to use the version from the master branch instead of the one from Hex.pm

I've just checked, we already using the latest version.

try to download the file using AWS.S3 after you upload it.

I tried via AWS.S3.get_object, it returns some content, however, it's not valid (I cant' play that mp3 if I write this content to file)

@Victoria91 thanks for trying out! Would you mind to check if the MD5 of the downloaded content is the same from what you are uploading? They are probably not the same, but I want just to confirm.

I've just checked, actually, the body and md5 are all the same, so I was mistaken before about different body, sorry.
As I've researched via S3 console, I've notice a difference between file uploaded via AWS.S3 and ExAws.S3 - it was Content-Type metadata, in case with ExAws.S3 it was 'application/octet-stream' while with AWS.S3 it was 'text/xml'.
So once I've set Content-Type along with other headers everything works fine!
I think maybe It's better to update README to add note about Content-Type

@Victoria91 this is interesting! and no problem. :)

I'm verifying if this is a bug. Apparently the Content-Type should be application/octet-stream because this operation can send the body as stream. If this is a bug, we shouldn't need to update the readme. I will let you know.