AWS S3 - CORS OPTIONS Preflight throwing 400 Bad Request during DELETE w/ VersionId

Question

I am attempting a deleteObject request for a delete marker using the Key of the object and the VersionID of the delete marker.

Because of CORS, the browser (Chrome 34.0.1847.11) sends an OPTIONS preflight request to: http://bucket.s3-us-west-2.amazonaws.com/Folder/File.ext?versionId=0123456789

Amazon S3 responds with 400 (Bad Request) with the following XML body:

<?xml version="1.0" encoding="UTF-8"?>
<Error>
    <Code>InvalidArgument</Code>
    <Message>This operation does not accept a version-id.</Message>
    <ArgumentValue>0123456789</ArgumentValue>
    <ArgumentName>versionId</ArgumentName>
    <RequestId>12345</RequestId>
    <HostId>1122334455</HostId>
</Error>

Because the XMLHttpRequest returns 400 (Bad Request), the DELETE request never gets executed. I am under the impression that AWS isn't handling the options request correctly. If there is a workaround, that would be great!

My current CORS policy on the bucket is:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>HEAD</AllowedMethod>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedMethod>PUT</AllowedMethod>
        <AllowedMethod>POST</AllowedMethod>
        <AllowedMethod>DELETE</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

FYI: I am using the AWS SDK for JS 2.0.0-rc10

Thank you in advance.

EDIT 1: I tried adding <AllowedMethod>OPTIONS</AllowedMethod> but Amazon returns Found unsupported HTTP method in CORS config. Unsupported method is OPTIONS

EDIT 2:

OPTIONS request/response headers:

Remote Address: *********:443
Request URL: https://bucket.s3-us-west-2.amazonaws.com/path/to/file_name?versionId=0123456789
Request Method: OPTIONS
Status Code: 400 Bad Request

Request Headers
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Access-Control-Request-Headers: x-amz-user-agent, x-amz-security-token, x-amz-date, authorization, content-type
Access-Control-Request-Method: DELETE
Cache-Control: no-cache
Connection: keep-alive
DNT: 1
Host: bucket.s3-us-west-2.amazonaws.com
Origin: https://website.com
Pragma: no-cache
Referer: https://website.com/
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.60 Safari/537.36
Query String Parameters
versionId: 0123456789

Response Headers
Access-Control-Allow-Headers: x-amz-user-agent, x-amz-security-token, x-amz-date, authorization, content-type
Access-Control-Allow-Methods: HEAD, GET, PUT, POST, DELETE
Access-Control-Allow-Origin: *
Connection: close
Content-Type: application/xml
Date: Tue, 18 Mar 2014 23:59:15 GMT
Server: AmazonS3
Transfer-Encoding: chunked
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
x-amz-id-2: *************************
x-amz-request-id: ***********

The delete request doesn't ever actually happen because the OPTIONS fails.

Please include all HTTP request and response headers for OPTIONS and DELETE requests. By the way, I've heard about issues with passing parameters for DELETE method. And just in case, try `OPTIONS` :) — Adam, Mar 18 '14 at 14:31
@Adam - Please see Edit 1 and Edit 2. Be aware that the library/browser never actually gets to call DELETE because the OPTIONS pre-flight fails. Normal deletes without the versionId GET parameter in the OPTIONS pre-flight work perfectly fine. — ThievingSix, Mar 19 '14 at 00:07
According to **[the docs](http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectDELETE.html#ExampleVersionObjectDelete)** it should work. Try to pass the _versionId_ parameter inside the request body (like with POST) instead of the query string. This way it won't be checked by the CORS rules, which does not mean it will work. You can also inspect the traffic on a lower level with a network sniffer (sometimes browsers lie). — Adam, Mar 19 '14 at 01:05
@Adam - I don't generate any of the requests myself and I believe the browser automatically generates the OPTIONS request when you do the DELETE request due to CORS. I am using Amazons SDK for this. — ThievingSix, Mar 19 '14 at 01:06
Yes, the OPTIONS request is generated automatically and cannot be bypassed. I suppose the SDK creates the DELETE request for you, so you do not have much control, but you can always create a custom request using _jQuery_ or pure _XMLHttpRequest_ object. Also try with different browser. I also see the non-standard `DNT` header - try disabling the _Do Not Track_ option for a while. — Adam, Mar 19 '14 at 01:12

score 41 · Answer 1 · answered Jan 28 '15 at 06:54

41

I just ran into this problem. It only occurs on Chrome. It was pretty awesome.

The solution is to add the following to your relevant <CORSRule> configuration in AWS:

<AllowedHeader>*</AllowedHeader>

That makes Chrome NOT send the OPTIONS request, and everything should work properly.

answered Jan 28 '15 at 06:54

tmont

2,562
20
15

4

As a comment, this configuration is set by going to your s3 bucket, clicking on `Properties`, `Permissions`, and `Edit CORS Configuration` – Alfonso Embid-Desmet Aug 03 '16 at 17:34
I get 206 Partial Content – Dr Manhattan Mar 16 '17 at 03:59
5

This didn't help. I wish it did. – TheTC Jan 15 '19 at 20:54
apparently there's some issue between chrome and s3 negotiating CORS. this answer explain it fully and give some alternatives: https://serverfault.com/a/856948 – Pedro Andrade Mar 11 '19 at 20:15
4

@tmont I really doubt that CORS rules on S3 bucket make Chrome stop sending OPTIONS request, as Chrome is not aware about this rule in first place and OPTIONS is preflight method - it has to be executed always, according to my understanding of the mechanism. – tymik Sep 10 '20 at 10:44

AWS S3 - CORS OPTIONS Preflight throwing 400 Bad Request during DELETE w/ VersionId

1 Answers1