[ https://issues.apache.org/jira/browse/JCLOUDS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480093#comment-17480093 ]
Andrew Gaul commented on JCLOUDS-1595: -------------------------------------- [~jimse] could you open a pull request to fix this? You can run the jclouds integration tests for s3 via: {{ mvn integration-test -pl :s3 -Plive \}} {{ -Dtest.s3.endpoint="${JCLOUDS_ENDPOINT}" \}} {{ -Dtest.s3.identity="${JCLOUDS_IDENTITY}" \}} {{ -Dtest.s3.credential="${JCLOUDS_CREDENTIAL}"}} > ListBucketOptions methods should URLEncode values > ------------------------------------------------- > > 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 > > When org.jclouds.s3.options.ListBucketOptions calls {{queryParameters.put}} > any string values should be url encoded. > 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 it with escaped slashes (in the observed case, the delimiter was > "/" and the prefix ended with a "/". Both need to be escaped as %2F prior to > building the Authorization header. > 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." -- This message was sent by Atlassian Jira (v8.20.1#820001)