[
https://issues.apache.org/jira/browse/JCLOUDS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480550#comment-17480550
]
Andrew Gaul commented on JCLOUDS-1595:
--------------------------------------
Sounds reasonable but please compare with what AWS does.
> Aws4SignerBase.getCanonicalizedQueryString should not escape the slash char
> ---------------------------------------------------------------------------
>
> Key: JCLOUDS-1595
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1595
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
> Affects Versions: 2.4.0
> Reporter: Jim Sermersheim
> Priority: Minor
> Labels: s3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> org.jclouds.s3.filters.Aws4SignerBase#getCanonicalizedQueryString should
> leave the '/' char unescaped when it is being used by
> org.jclouds.s3.filters.Aws4SignerBase#createStringToSign
> As it is, it's escaping the '/' char in the query string, and this is not
> consistent with the actual query string that is used in the URL when making
> the HTTP request (the '/' is unescaped in that case).
> This is currently causing a bug when jclouds is used to list with a prefix
> against NetApp's ONTAP S3 server (version 9.10.1). The calculation of the S3
> V4 signature differs between JClouds and the NetApp because the NetApp is
> calculating the signature witn unescaped slashes (which is what the client
> sent in the URL)
> For reference, the error coming back from the NetApp ONTAP is a 403 with the
> message: "The request signature we calculated does not match the signature
> you provided. Check your key and signing method."
> Other S3 servers must be more lenient in this regard, or perhaps don't
> validate the signature.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
