Bucket Name

SaltwaterC edited this page Jul 30, 2012 · 1 revision

General bucket naming limitations

The bucket name should obey the Bucket Restrictions and Limitations document.

Please notice that the S3 API supports the (not recommended) path based addressing, as opposed to host based addressing that the S3 API refers to as "virtual hosting". This can lead to weird behavior such as requests failing for no apparent reason. Unfortunately, due to the way the S3 API implements the path based addressing, in production you may get bucket names that are not compatible with addressing methods.

If you want to avoid surprises, always use lowered case names when creating a new bucket.

Here's the deal:

  • the path names are case sensitive aka 'MyBucket' is different than 'mybucket'.
  • the host names are not case sensitive aka 'MyBucket' is the same as 'mybucket'.

If you create a new bucket by using the path based addressing as 'MyBucket', anyone that tries to use the host based addressing gets a 403 HTTP error for no apparent reason.

HTTPS bucket naming limitations

If you're using S3 over the HTTPS protocol, more restrictions apply for the bucket naming and addressing. This isn't properly documented into the S3 upstream documentation.

The S3 servers provide a wildcard certificate for *.s3.amazonaws.com. However, if your bucket contains the dot character, things may not work as you expected:

  • a bucket name like 'foo' using the host based addressing has this host: foo.s3.amazonaws.com. This works as expected for the HTTPS clients.
  • a bucket name like 'foo.bar' using the host based addressing has this host: foo.bar.s3.amazonaws.com. You may expect that the wildcard certificate also covers the next level from the host hierarchy, but it doesn't. Using a host like this usually leads to SSL certificare errors into the HTTPS client. In order to have it work properly, S3 needs a certificate that covers *.bar.s3.amazonaws.com, but it is quite obvious that it won't happen. You need to revert to using the path based addressing in this specific case.
https://foo.s3.amazonaws.com/object.ext => good
https://foo.bar.s3.amazonaws.com/object.ext => BAD
https://s3.amazonaws.com/foo.bar/object.ext => good