PermanentRedirect error for g_region_eu_frankfurt ( eu-central-1 )

[apeaks999]

Hi,

I am getting mentioned below error when trying to upload files into bucket created to region EU (Frankfurt).

PermanentRedirect

The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.

Any quick workaround for this?

[cmoore-sp]

I have re-created your error. I created a bucket in Frankfurt (eu-central-1). The error message is telling me this:

<Error>
<Code>PermanentRedirect</Code>
<Message>
The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.
</Message>
<Bucket>test-stormpetrel</Bucket>
<Endpoint>test-stormpetrel.s3.amazonaws.com</Endpoint>
<RequestId>C51B6412854833AD</RequestId>
<HostId>
dP8rh90UeT8lKCqubuLmKxETnEfzP7MHRcIyVcSoltdVTuf8+HZ8fE21nwl/mUFnzjb3hZn7P4Y=
</HostId>
</Error>

and my URL was this: https://s3.amazonaws.com/test-stormpetrel/

The AWS Documentation showed both:

• my-bucket.s3.amazonaws.com and
• s3.amazonaws.com/my-bucket

I'll study this and post an update. cmoore (25FEB2017)

[cmoore-sp]

The syntax for the original us-standard (now called us-east-1) bucket does not seem to follow the same rules for the newer buckets. In the comments for function "Canonical Request", I observed two options in the AWS documentation.

I solved the problem by adding a IF statement. If 'us-east-1' use the older syntax. ELSE use the newer syntax.

The revised code is posted.

*cmoore (25feb2017)

[apeaks999]

Hello cmoore-sp,

Thank you very much for taking a very quick look and prompt action to revise the package.

I will check with the new code.

Once again thanks.

[apeaks999]

Hi Christina,

I had executed the updated code. The error has been changed now. It's point to signature mismatch.

I am attaching error log. Can you please give direction in right way. I've checked the id & key are correct and working using old API for the Singapore region.

26.02.2017 13:41:45: 
<?xml version="1.0" encoding="WINDOWS-1256"?>
<Error>
  <Code>SignatureDoesNotMatch</Code>
  <Message>The request signature we calculated does not match the signature you provided. Check your key and signing
method.</Message>
  <
AWSAccessKeyId>#MyAccessKey#</AWSAccessKeyId>
  <StringToSign>AWS4-HMAC-SHA256
20170226T094143Z
20170226/eu-central-1/s3/aws4_request
30cbb68a0bdf25bc66f848ae323e30520a71a1bb13b5785c165ae7b612a72716</StringToSign>
  <SignatureProvided>eda032bb
523047aaa4be9446a8ef6dbe5c504efe13ebd5d8777397efe7c15d87</SignatureProvided>
  <StringToSignBytes>41 57 53 34 2d 48 4d 41 43 2d 53 48 41 32 35 36 0a 32 30 31 37 30 32 32 36 54 30 39 34 31 34 33 5a 0a 32 30 31 37 30 32 32 36 2f 65 75 2d 63 65 6e 74 72
 61 6c 2d 31 2f 73 33 2f 61 77 73 34 5f 72 65 71 75 65 73 74 0a 33 30 63 62 62 36 38 61 30 62 64 66 32 35 62 63 36 36 66 38 34 38 61 65 33 32 33 65 33 30 35 32 30 61 37 31 61 31 62 62 31 33 62 35 37 38 35 63 31 36 35 61 65 37 62 36 31 32 61 37 32 37 
31 36</StringToSignBytes>
  <CanonicalRequest>PUT
/the-floating-152709_1.jpg

host:mybucket-ge.s3.eu-central-1.amazonaws.com
x-amz-content-sha256:d6c2f66d76dbce975e6f76d4a6cc0897fde64dbca9bde2851fb085bee8323339
x-amz-date:20170226T09414
3Z

host;x-amz-content-sha256;x-amz-date
d6c2f66d76dbce975e6f76d4a6cc0897fde64dbca9bde2851fb085bee8323339</CanonicalRequest>
  <CanonicalRequestBytes>50 55 54 0a 2f 74 68 65 2d 66 6c 6f 61 74 69 6e 67 2d 73 65 61 68 6f 72 73 65 2d 31
35 32 37 30 39 5
f 31 2e 6a 70 67 0a 0a 68 6f 73 74 3a 66 61 6d 70 72 6f 70 65 72 74 69 65 73 2d 67 65 2e 73 33 2e 65 75 2d 63 65 6e 74 72 61 6c 2d 31 2e 61 6d 61 7a 6f 6e 61 77 73 2e 63 6f 6d 0a 78 2d 61 6d 7a 2d 63 6f 6e 74 65 6e 74 2d 73 68 61 32 35 36 3a 64 36 63
 32 66 36 36 64 37 36 64 62 63 65 39 37 35 65 36 66 37 36 64 34 61 36 63 63 30 38 39 37 66 64 65 36 34 64 62 63 61 39 62 64 65 32 38 35 31 66 62 30 38 35 62 65 65 38 33 32 33 33 33 39 0a 78 2d 61 6d 7a 2d 64 61 74 65 3a 32 30 31 37 30 32 32 36 54 30 
39 34 31 34 33 5a 0a 0a 68 6f 73 74 3b 78 2d 61 6d 7a 2d 63 6f 6e 74 65 6e 74 2d 73 68 61 32 35 36 3b 78 2d 61 6d 7a 2d 64 61 74 65 0a 64 36 63 32 66 36 36 64 37 36 64 62 63 65 39 37 35 65 36 66 37 36 64 34 61 36 63 63 30 38 39 37 66 64 65 36 34 64 6
2 63 61 39 62 64 65 32 38 35 31 66 62 30 38 35 62 65 65 38 33 32 33 33 33 39</CanonicalRequestBytes>
  <RequestId>671278C978B2ED00</RequestId>
  <HostId>hAzOPnNxaNMRwCDTyIzol47QQPereCepDRGlJSDeLCDBqoXsZnbHmjLbABdrB6lqu1eiFZQPZLw=</HostId>
</Error>

[cmoore-sp]

When debugging I see this error often. It typically means that the Canonical Request doesn't match the URL (or what we think the Canonical Request should be). After I finish our maintenance window, I'll test what I worked on yesterday to PUT 1 JPG in Frankfurt.

Please turn on some debugging in the package, then send me:

• the Canonical Request the package creates
• the URL the package creates
• And the corresponding error message
  • This will include the Canonical Request that AWS "thinks" we meant. By comparing the generated Canonical Request with the AWS "calculated" request, we can see the issue.

Can you give me your name? We could track each other down via email.

[apeaks999]

Hi Christina,

Thanks for the prompt response.

I have checked now and come up with error on debug.

If we use region other than us-east-1 the as per API our url became like this :

https://example-bucket.s3-website.eu-central-1.amazonaws.com/

And for this one we will have the wildcard SSL certificate. And that is not supported by oracle wallet manager :-1:

Can we try using any other url pattern for the access end point? I am not gone through detail endpoint patterns. But will check on that.

Please provide yours too..

[apeaks999]

Is it feasible to use intermediate url redirect methodology to bypass this one as workaround ?

[cmoore-sp]

When working with 12c you must install the root and intermediate cert. I have now posted the two DigiCert SSL certificates here on github. There are instructions regarding this in the documentation area of this github.