Direct S3 CORS Doc: Shouldn't we allow OPTIONS method as well?

I guess we should include it here for preflight requests, shouldn’t we?

@janko, I’m not sure is it supposed to be a GitHub issue or a post here. So here it is. :slight_smile:

If you’re referring to the OPTIONS request that’s 404-ing for direct uploads, I don’t think it’s actually related with bucket CORS configuration. Uppy changed its behaviour to send an OPTIONS request to the backend (not S3) for any HTTP verb (the default preflight request is only for unsafe verbs, such as POST or PUT).

I think what we need to do is add an OPTIONS route to the presign_endpoint Rack app (and uppy-s3_multipart as well), which returns a response that the subsequent GET request is allowed. I don’t know what that response should return exactly, I’d welcome contributions for that. I could also open an issue for that and mark it as “easy for newcomers”, as I expect it just requires a bit of CORS knowledge.

Hey, thanks for a quick reply!

We have actually received that CORS-related error from S3, not our backend, and it was without Uppy, and I guess it’s just a little mistake on our frontend.

As for OPTIONS requests to presign_endpoint Rack app - I believe it’s already covered (at least in Rails). I use it for a long time already on another Rails project and didn’t have any issues with it.

I’m not sure what’s the situation in non-rails apps though, as I do not know which exact middleware actually takes care of those OPTIONS preflight requests by default for us.

I believe it is rack-cors gem that takes care of it here.
So basically any rack-based app can use it and have it covered.
So you just might want to mention it in that doc and we’re good! :slight_smile:

UPDATE: So it really was just a frontend mistake, it was sending one extra header, which was not allowed on S3, so your current Direct S3 CORS Doc is good! :slight_smile: