Amazon has changed the rules for bucket names, you no longer can do upper case bucket names and bucket names no longer can use “_”.
We have find out because today a couple of testcase did no longer path, until yesterday everything was fine.
Sadly the exception thrown is not really helpful: “The specified bucket is not valid.”.
So we consider 2 changes to the S3 Extension
- make a proper exception message that maybe also print out the rules for bucket names
- auto convert bucket names to lower case (maybe need a flag to enable)
IMO The “CFML way” is to lowercase the names automagically so that the filesystem becomes virtually case-insensitive, like most CFML constructs (with the exception of *nix file systems).
but we only talk about buckets here… folders are still case sensitive
I see.
Still though, I think that lowercasing is appropriate since the user will not be able to create the bucket with MiXed case anyway.
you no longer can create upper case buckets but existing are still fine, so you still can have multople buckets with the same name but different case.
If we do this, we should habe a flag for it.
this.s3.casesensitive=true;
I’d propose this.s3.lowercase instead, so default is false, opt-in with true.
But it still doesn’t refer to the bucket portion, suggesting that it is all affected which is incorrect.
Maybe a better name is needed.
as detail for the exception?
"could not create the bucket ["+bucketName+"], please consult the following website to learn about Bucket Restrictions and Limitations: https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html"
Keep in mind that these days S3 is a common standard rather than just an Amazon API
i.e. Azure and Google also provide S3 services, plus there are plenty of other implementations
Shouldn’t the exception just pass thru whatever error the API returns, or is the API error too cryptic and confusing?
these global settings per application preclude working with different end points which require different settings?
1 Like