Question about s3 CORS uploads (content-type header specifically)

[nspierre-indeed]

Hey folks! I've managed to make a pretty basic integration of fetching a pre-signed s3 upload url and then using axios to perform a PUT operation on it (obviously cross-domain, from our hosted one to the s3 one). The basic code looks like this:

const res = await axios.put(path.toString(), file.data, {
        onUploadProgress: onProgress,
        signal
    });

This works great! I see a pre-flight request go through and the whole thing works, the onUploadProgress hook populates correctly, we can put a terminate signal in. However, we learned that our files ended up in s3 with the filetype of "application/x-www-form-urlencoded". Obviously, it looks like that's the default header sent with this PUT request. So, I tried testing this with passing that header in.

const res = await axios.put(path.toString(), file.data, {
        onUploadProgress: onProgress,
        signal,
        headers: {
          'content-type':file.type
        }
    });

This does NOT work. At first I thought it was because my presigned url had a specific content-type, but it turns out I can copy the XHR as a curl from chrome and run it, and it works fine. Here's the part of my investigation that confuses me (and may just be underlying browser standards I don't understand).

The one that works contains the following headers:

'Sec-Fetch-Site: cross-site' 
'Sec-Fetch-Mode: cors' 
'Sec-Fetch-Dest: empty'

The one that doesn't work does not have those, but I didn't modify any of that. Is that a factor? Is this something to do with the underlying fetch/xhr implementation in axios? Any help you can give me would be greatly appreciated!

[jasonsaayman]

Hi, this should work, for example from my own code base I do the exact same thing:

await axios.put( data.uri, data.file, { headers: { 'Content-Type': data.file.type, }, }, )

[nspierre-indeed]

Yeah, that's exactly what I did, but it results in a 403 on the pre-flight. It's possible it's an s3 config, but the part that confuses me is why those Sec-Fetch headers change if you set the content-type header.

[nspierre-indeed]

Actually I think I'm wrong, I pulled it down again and the only difference is the OPTIONS call appears to send this: Access-Control-Request-Headers: content-type

Since that's a 403 I think it's likely an s3 thing, so I'll dig into that and post any findings here if anyone else runs into this.

[nspierre-indeed]

Yup, we needed this: allowed_headers = ["*"] in our cors_rules.