Using swift3/test/functional/s3curl.pl createBucket option returns SignatureDoesNotMatch due Header contains Content-Type
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Swift3 |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
--By using createBucket option from swift3/
e.g: # ./s3curl.pl --id=personal_ks --createBucket -- -v http://
* About to connect() to es-node1 port 8080 (#0)
* Trying 172.22.1.10...
* Connected to es-node1 (172.22.1.10) port 8080 (#0)
> PUT /newBucket23 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: es-node1:8080
> Accept: */*
> Date: Thu, 09 Oct 2014 18:26:59 +0000
> Authorization: AWS 24ebedc0e10f400
> Content-Length: 0
> Content-Type: application/
>
< HTTP/1.1 403 Forbidden
< x-amz-id-2: txdebd53aca3774
< x-amz-request-id: txdebd53aca3774
< Content-Type: text/xml
< X-Trans-Id: txdebd53aca3774
< Date: Thu, 09 Oct 2014 18:26:59 GMT
< Transfer-Encoding: chunked
* HTTP error before end of send, stop sending
<
<?xml version='1.0' encoding='UTF-8'?>
* Closing connection 0
<Error>
--By removing Content-Type header or doing the request without Content-Type the request succeed. --
--Alternative requests form:--
$ ./s3curl.pl --id personal_ks --createBucket -- -H “Content-Type:” http://<AWS endpoint>
$ ./s3curl.pl --id personal_ks -- -X PUT http://<AWS endpoint>
Expected: Using s3curl.pl script --createBucket succeed without provide extra header values to remove content-type.
Changed in swift3: | |
status: | New → Incomplete |
This does not look a swift3 bug. In my experiment, swift3 seems to calculate a correct signature.
This seems to be caused from that s3curl does not put the content-type header into string-to-sign when it is overridden by "-H" option. (If you want to know about string-to-sign in detail, please see S3 documentation here, http:// docs.aws. amazon. com/ja_ jp/AmazonS3/ latest/ dev/RESTAuthent ication. html) x-www-form- urlencoded" by default. However, when I specified content-type via s3curl client by using "--contentType" option instead of -H overriding, it seemed to generate a correct signature and work well.
I don't know why your s3curl client uses "Content-Type: application/
e.g. x-www-form- urlencoded --createBucket -- http://<AWS endpoint> :8080/< bucket_ name>
./s3curl.pl --id personal_ks --contentType application/
This worked well to me.