Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S3 createBucket sends us-east-1 region by default #919

Closed
gaul opened this issue Mar 1, 2016 · 7 comments
Closed

S3 createBucket sends us-east-1 region by default #919

gaul opened this issue Mar 1, 2016 · 7 comments
Assignees

Comments

@gaul
Copy link

gaul commented Mar 1, 2016

Instead it would be better for it to send no location when not specified. This will default to us-east-1 for aws and allow third-party implementations to default to their correct behavior.

@LiuJoyceC
Copy link
Contributor

Hi @andrewgaul
Could you provide more information about your use case and why you want no location to be specified?

If you are looking to change the default region so that you don't need to specify the region each time you call the createBucket operation, you can instantiate your S3 instance with var s3 = new AWS.S3({region: REGION_NAME}). You can also change the default location using AWS.config.update({region: REGION_NAME}). Then any S3 instance objects (or any other service instance) created after this configuration is set will default to your specified region.

@gaul
Copy link
Author

gaul commented Mar 2, 2016

@LiuJoyceC Some S3 implementations, e.g., S3Proxy, do not have a notion of regions. Requiring users to configure this is confusing and diverges from how other AWS SDKs work, e.g., Java SDK, which send no region when not configured.

@chrisradek
Copy link
Contributor

@andrewgaul
If no region is specified, the SDK uses the s3.amazonaws.com endpoint when making a request. According to the S3 docs, when this endpoint is used, the request goes to the us-east-1 region:
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUT.html
Note If you send your create bucket request to the s3.amazonaws.com endpoint, the request go to the us-east-1 region. Accordingly, the signature calculations in Signature Version 4 must use us-east-1 as region, even if the location constraint in the request specifies another region where the bucket is to be created.
The documentation for LocationConstraint on the same page also shows that the default region, if none is provided, is us-east-1.

I'm not sure we could change this behavior if we wanted to, but if we did, this would be a breaking change for customers that are creating buckets in us-east-1 without specifying a region.

@gaul
Copy link
Author

gaul commented Mar 2, 2016

@chrisradek The quoted passage requires a region specified in the v4 signature but not the location constraint, which defaults to us-east-1 on AWS and whatever is appropriate for third party implementations. Specifically I want the node.js SDK to match the Java SDK behavior, for example:

D 03-01 17:28:59.247 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "Host: 127.0.0.1:59770[\r][\n]"
D 03-01 17:28:59.247 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "x-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855[\r][\n]"
D 03-01 17:28:59.248 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "Authorization: AWS4-HMAC-SHA256 Credential=local-identity/20160302/us-east-1/s3/aws4_request, SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date, Signature=30c3e1e03db913997d035f1f728c03e551466a7c5e2f7d6d11a965591fa18992[\r][\n]"
D 03-01 17:28:59.248 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "X-Amz-Date: 20160302T012859Z[\r][\n]"
D 03-01 17:28:59.248 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "User-Agent: aws-sdk-java/1.10.50 Linux/3.13.0-79-generic Java_HotSpot(TM)_64-Bit_Server_VM/25.74-b02/1.8.0_74[\r][\n]"
D 03-01 17:28:59.249 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "Content-Type: application/octet-stream[\r][\n]"
D 03-01 17:28:59.249 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "Content-Length: 0[\r][\n]"
D 03-01 17:28:59.249 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "Connection: Keep-Alive[\r][\n]"
D 03-01 17:28:59.249 pool-1-thread-2 org.apache.http.wire:72 |::]  >> "[\r][\n]"

Note that no location constraint is specified, i.e., no entity body.

@chrisradek
Copy link
Contributor

@andrewgaul
Sorry if I'm not understanding what you're asking for exactly.

If the user doesn't specify a location constraint, and no region is defined, the SDK doesn't send a location constraint.

Quick test code:

//If AWS_REGION wasn't set, then AWS.config.region should be undefined
var s3 = new AWS.S3({signatureVersion: 'v4'});
s3.createBucket({Bucket: 'myNewBucket'}, function(err, data) {});

Result when inspecting request.httpRequest.stream._headers

PUT / HTTP/1.1\r\n
User-Agent: aws-sdk-nodejs/2.2.35 darwin/v0.12.9\r\n
Content-Type: application/octet-stream\r\n
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\r\n
Content-Length: 0\r\n
Host: myNewBucket.s3.amazonaws.com\r\n
X-Amz-Date: 20160302T160915Z\r\n
Authorization: AWS4-HMAC-SHA256 Credential=xxx/us-east-1/s3/aws4_request,SignedHeaders=host;x-amz-content-sha256;x-amz-date,Signature=55b5ed5aa5f55b5fc55c7810ff32f9cb80ea6a6001a75367faef6d4d4e7fd401\r\n
Connection: close\r\n
\r\n'

You'll notice the Content-Length is 0 in this case; we aren't providing a location constraint.

If the user has a region defined in a region other than us-east-1, then the SDK will automatically set the location constraint to match the region that was defined if no location constraint was provided.
https://github.com/aws/aws-sdk-js/blob/master/lib/services/s3.js#L417

So, it looks like we are behaving the same way as the Java SDK when no region is defined.

What behavior are you seeing exactly? Maybe an example would help us understand better.

@chrisradek
Copy link
Contributor

Closing this issue as it looks like our SDK is behaving the same as the Java SDK when no region is defined in the SDK. Please feel free to comment if more clarification is needed, or you have more details to share.

@lock
Copy link

lock bot commented Sep 29, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.

@lock lock bot locked as resolved and limited conversation to collaborators Sep 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants