Using swift3/test/functional/s3curl.pl createBucket option returns SignatureDoesNotMatch due Header contains Content-Type

[ariday]

--By using createBucket option from swift3/test/functional/s3curl.pl script, it returns error: SignatureDoesNotMatch- The request signature we calculated does not match the signature you provided. Check your key and signing method.--

e.g: # ./s3curl.pl --id=personal_ks --createBucket -- -v http://es-node1:8080/newBucket23
* 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 24ebedc0e10f400b9ebdc33b05cc322b:jKBWxuk0TPR9oohG/G7Z07hKi9A=
> Content-Length: 0
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 403 Forbidden
< x-amz-id-2: txdebd53aca377408dab75b-005436d373
< x-amz-request-id: txdebd53aca377408dab75b-005436d373
< Content-Type: text/xml
< X-Trans-Id: txdebd53aca377408dab75b-005436d373
< 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><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><RequestId>txdebd53aca377408dab75b-005436d373</RequestId></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>:8080/<bucket_name>
$ ./s3curl.pl --id personal_ks -- -X PUT http://<AWS endpoint>:8080/<bucket_name>

Expected: Using s3curl.pl script --createBucket succeed without provide extra header values to remove content-type.

[Kota Tsuyuzaki (tsuyuzaki-kota)]

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/RESTAuthentication.html)
I don't know why your s3curl client uses "Content-Type: application/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.

e.g.
./s3curl.pl --id personal_ks --contentType application/x-www-form-urlencoded --createBucket -- http://<AWS endpoint>:8080/<bucket_name>

This worked well to me.

[Darryl Tam (dtam)]

I encountered this issue today. I can confirm it's an issue with s3curl and not swift3 with the same resolution: Specifying the content-type with the s3curl --content-type option instead of a curl -H option.