@siddhant1 I’ve had to resort to the fix by @giorgio.scavuzzo to be able to retrieve images from R2 as array buffers using fetch. I have configured the allowed domains using the UI but without the aforementioned fix, it still wouldn’t work.
Could you kindly look into this?
I am unable to edit my post above so I’m posting the fix here.
The reason I was facing CORS errors was because was loading the same image separately using an img tag. The browser was caching that request which did not have the required CORS headers, resulting in an error. I fixed it by simply adding crossorigin=“anonymous” to the img tag so that the cached image request has the required CORS headers.
i tried to apply CORS from R2 dashboard, with custom domain settings, And I added the file to the website which I have set in AllowedOrigins"(in this case I tried the .mp4 file).And I get error’ 400 response in browser console.
Is there any solution?
I’m with the same problem.
I’m using preSignedUrl for Upload file. (PutCommand)
When I Tried to upload from http://localhost:4200 the OPTIONS request return 204 (OK) but the PUT request returns 400 with No 'Access-Control-Allow-Origin ERROR.
The response on OPTIONS request show the CORS headers:
But the PUT request no:
[
{
"AllowedOrigins": [
"*"
],
"AllowedMethods": [
"GET",
"PUT",
"POST",
"HEAD"
],
"AllowedHeaders": [
"*"
],
"MaxAgeSeconds": 2
}
]
What is the body of the 400 response?
The body is the binary of file (csv) to upload.
The error on console is: has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
I Fixed here now!
changed the AllowedHeaders to:
“Content-Type” instead of *
My issue is exactly like @robson’s: The OPTIONS (preflight) request gets a 204 response with Access-Control-Allow-Origin: *, which is what I had set in the CORS policy. So far, so good. However, the subsequent POST request gets back a 400 and doesn’t have any CORS headers. (Also, explicitly enumerating allowed headers like the above comment suggests, doesn’t help).
We are using POST, not PUT, because some options that we need (such as dynamic conditions on the upload path and content type, such as ["starts-with", "$key", "user/user1/"]) are only available with POST requests (AWS docs https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-HTTPPOSTConstructPolicy.html and https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-post-example.html).
Could it be that the R2 doesn’t implement this (POST) endpoint at all (yet)?
I see you added a lot of docs since I last looked into this, and also a CORS policy editor (thanks for that, it saves a lot of messing around with cURL and Postman 
). I’ll take another look at the docs to see if there’s anything you added there that may provide some hints.
Sorry, the spam filter kicked in and I accidentally double posted. I deleted the 2nd post now.
You tried add the AllowedHeaders to only “Content-Type” ?
Yes, I did try that, getting the exact same error.
R2 doesn’t support S3 POST yet, no.
Thanks!
This is a blocker for us unfortunately. Is this mentioned anywhere in the official docs? Are there any plans to add support for this?
The only real mention of it is the lack of the mention of it - it’s not listed as implemented on the S3 API page, but also isn’t listed as unimplemented.
Thanks, yeah, I saw that doc too. Weird that they mention unimplemented functionality for the bucket level operations, but not for the object level ones 
I addedand tried several cors rules just to be sure. But can not get the “Access-Control-Allow-Origin” header as a response from Cloudflare.
It seems to be a bug.
My cor rules are as follows.
> [
> {
> "AllowedOrigins": [
> "http://localhost:3000"
> ],
> "AllowedMethods": [
> "GET",
> "PUT",
> "POST",
> "DELETE",
> "HEAD"
> ],
> "AllowedHeaders": [
> "*"
> ],
> "ExposeHeaders": [
> "Content-Encoding",
> "cf-cache-status",
> "sDate",
> "access-control-allow-origin"
> ]
> },
> {
> "AllowedOrigins": [
> "*"
> ],
> "AllowedMethods": [
> "PUT"
> ],
> "AllowedHeaders": [
> "Content-Type",
> "Content-Length"
> ]
> },
> {
> "AllowedOrigins": [
> "*"
> ],
> "AllowedMethods": [
> "GET",
> "HEAD"
> ]
> },
> {
> "AllowedOrigins": [
> "*"
> ],
> "AllowedMethods": [
> "GET"
> ],
> "AllowedHeaders": [
> "*"
> ]
> }
> ]
Hey folks, sorry I haven’t been following this thread very closely.
It sounds like a lot of people are trying a presigned POST requests, which are not supported currently, unfortunately (this is now documented, thanks for pointing this out!).
I understand that debugging CORS policies can be hard because you do not control the “server” / CORS headers aren’t usually very helpful. We added this section to our docs that also explains how to set up CORS for object uploads via presigned URLs: Configure CORS · Cloudflare R2 docs , which should make things clear(er). If there are things you’d want added here, please reach out.
If you still run into issues, I’ll be happy to debug things with you on Discord: Cloudflare Developers, just shout in the r2-storage channel.
@rtopuz What would also help is showing me what request you’re sending out. CORS policies are just one half of the setup 
H,
my request is very simple. just trying to get an image from Cloudflare bucket. But unfortunately, I can not get it, even the bucket is public and I tried to configure cors at Cloudflare.
https://pub-…r2.dev/2023/04/13/agac1.jpeg
GET
200 OK
strict-origin-when-cross-origin
@siddhant1 Thanks for clearing things up. Are presigned POSTs on your roadmap at all or is this something we shouldn’t expect any time soon?