You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to information from the forums located here ( https://forums.aws.amazon.com/ann.jspa?annID=6776 ), the path naming will need to be updated to always use https://.s3./ instead of https://s3.//. Currently that pattern is used for us-east-1 as the region, but not for non-us-east-1 or CN regions.
Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com//key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //.s3.amazonaws.com/key). In our effort to continuously improve customer experience, the path-style naming convention is being retired in favor of virtual-hosted style request format. Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.
Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.
If there is any reason why your application is not able to utilize the virtual-hosted style request format, or if you have any questions or concerns, please reach out to AWS Support.\
We may also want to adjust the parse_url logic to return the base awsurl to remove the case statement that does not work for other regions that use a different AWS endpoint, but that can be covered in another issue.
One issue that may be worth addressing as a part of this change - if a bucket name has a . in it, do we properly send a warning/error up to the user of this plugin? Is there a reasonable exception that gets flowed up, or should we manually add the warning to the case?
The text was updated successfully, but these errors were encountered:
According to information from the forums located here ( https://forums.aws.amazon.com/ann.jspa?annID=6776 ), the path naming will need to be updated to always use https://.s3./ instead of https://s3.//. Currently that pattern is used for us-east-1 as the region, but not for non-us-east-1 or CN regions.
We may also want to adjust the parse_url logic to return the base awsurl to remove the case statement that does not work for other regions that use a different AWS endpoint, but that can be covered in another issue.
One issue that may be worth addressing as a part of this change - if a bucket name has a
.
in it, do we properly send a warning/error up to the user of this plugin? Is there a reasonable exception that gets flowed up, or should we manually add the warning to the case?The text was updated successfully, but these errors were encountered: