Content-Type question

10 views
Skip to first unread message

Greg Beresnev

unread,
Apr 25, 2016, 7:08:18 PM4/25/16
to JetS3t Users
Hi,

I'm using version 0.9 of jet3t at the moment, and uploading binary data to S3 bucket. Initially the uploading was done from Java client, and the s3service.createSignedPutUrl call was not passed any header values, and everything was working reasonably well. Later on I tried doing binary uploads from javascript client and noticed that 'Content-Type' header was sent in the upload request, which caused it to fail (presumably because the createSignedPutUrl call did not specify any references to such a header). Which brings the question - what're my options at this stage? Should I be able to upload a file to S3 from browser without specifying the Content-Type header at all? Is there some Content-Type header value I can use which matches the S3 under-the-covers default? The last option is obviously to update the createSignedPutUrl and explicitly specify a value like 'application/octet-stream' but I'm checking my other options before I head down that path..

suggestions/comments appreciated,
Greg

James Murty

unread,
Apr 26, 2016, 7:49:04 AM4/26/16
to jets3t...@googlegroups.com
Hi Greg,

If you want to avoid having the Content-Type header set, I think your best option is to find where the Javascript file-uploading code is setting this header then prevent it, or at least make sure that it is always set to the same value – "application/octet-stream" would be a reasonable default.

S3 itself doesn't have any default content type, though it is standard practice to set this header with a value appropriate for the file being uploaded. However this is difficult with a pre-generated signed PUT form, since you probably won't know in advance exactly what type of file will be uploaded (e.g. an image might be a jpeg, a gif, etc etc...)

The easiest thing would be to set your own default like "application/octet-stream" in the Javascript client, then generate the signed PUT form with this content type.

If you need to properly support different file content types that you don't know in advance, you might be able to do this by dynamically requesting a new PUT from your server with the appropriate Content-Type header etc once you know what kind of file will be uploaded. That is, start off with a generic PUT form but obtain and use a brand new file-specific PUT form to do the actual upload to S3. But this would get pretty complicated...

Hope this helps,
James



--
You received this message because you are subscribed to the Google Groups "JetS3t Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jets3t-users...@googlegroups.com.
To post to this group, send email to jets3t...@googlegroups.com.
Visit this group at https://groups.google.com/group/jets3t-users.
For more options, visit https://groups.google.com/d/optout.

Greg Beresnev

unread,
Apr 26, 2016, 9:50:10 PM4/26/16
to JetS3t Users
Thanks James

I managed to figure out how to prevent Content-Type header from being sent to S3 as a part of PUT request in my javascript client, and this seems to do the trick (i.e. javascript behaviour now matches that of my java client)

regards,
Greg
Reply all
Reply to author
Forward
0 new messages