Support punycode bucket/alias mapping in the webserver #273
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#273
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Would it make sense to support punycode in the webserver? For example I have a website that uses the Danish letter
ø
, which e.g. nginx and haproxy support as long as I convert it to punycode everywhere.It's directly against the spec for bucket names, but perhaps it could be supported in aliases?
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
The obvious workaround is that I have to re-configure my haproxy to rewrite the domain name, but it's not as clean.
The validation logic of the bucket name is here in the code: https://git.deuxfleurs.fr/Deuxfleurs/garage/src/branch/main/src/model/bucket_alias_table.rs#L66-L90
Earlier, in the projet design, we discussed the possibility of diverging from the S3 spec by using some flags. We might want to add some configuration flags to disable parts of the bucket name validation process.
eg.
Hmm, I thought this would be a simple fix, but since
is_valid_bucket_name
is a public function in the root it can't access variables inBucketAliasTable
, which I was going to instantiate with a copy of the s3_api config.It seems like the only way, to get the config values into the function, is to update the signature and pass the problem up to the caller. Which means updating ~6 uses. A few of those don't have access to the config either, pushing the problem further up.
Maybe there's a better way?
Basically we have two options to make this happen:
pass the relevant config variables all the way down to
is_valid_bucket_name
, which means passing this as a parameter to many intermediate functions, which is quite cumbersomeput Garage's configuration, or part of it, in a global variable
I think solution 2 is probably what we want, see details in #292.