add proper request router for s3 api #163
No reviewers
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
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#163
Loading…
Reference in a new issue
No description provided.
Delete branch "trinity-1686a/garage:s3-router"
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?
fix #161
Current request router was organically grown, and is getting messier and messier with each addition.
This router cover exaustively existing API endpoints (with exceptions listed in #161(comment) either because new and old api endpoint can't feasabily be differentied, or it's more lambda than s3).
b8f214876b
toedac39409a
edac39409a
todff2977561
dff2977561
to5d7b6c41b5
1b3203fdc2
to41f83cff67
WIP: s3-routerto s3-routers3-routerto add proper request router for s3 apiapi_server::parse_bucket_key
should probably be reverted to before it supported vhost-style bucket, as it's now used only to parse bucket name and key from headers in CopyObject.Thanks trinity for this impressive PR. I'm very enthousiastic about merging it, my only worry is that we haven't checked that all of the endpoints we previously had implemented still work correctly (i.e. there are no bugs in the parser that affect the routes Garage implements). We'll talk about a testing strategy for this but we can still merge into
main
in the meantime.Just a small comment, regarding
s3_router.rs
line 500: how does AWS S3 behave if we give additionnal parameters that are not useful for the query? If it throws an error we should keep the current code that throws an error, but if it silently ignores them we should just do that.@ -267,0 +231,4 @@
handle_list(
garage,
&ListObjectsQuery {
is_v2: list_type == "v2",
At this point we should probably return 400 bad request if
list_type
is not equal to"v2"
. It doesn't make much sense callinghandle_list
withis_v2 = false
here because the arguments we are giving are those of ListObjectsV2: continuation_token, start_after, etc.(question: what happens on AWS S3 if we give a list_type value that is not "v2" ?)
@ -267,1 +247,4 @@
Endpoint::DeleteObjects { bucket } => {
handle_delete_objects(garage, &bucket, req, content_sha256).await
}
_ => Err(Error::BadRequest("Unsupported call".to_string())),
TODO (not necessarily in this PR): add a new error type so that we return HTTP 501
I have no idea. I'll get some free-tier S3 to check it out