[] Support CORS container for CORS settings #220

Merged
alexvanin merged 1 commit from mbiryukova/frostfs-http-gw:feature/cors_container into master 2025-03-12 06:33:58 +00:00
Member

Closes

Signed-off-by: Marina Biryukova m.biryukova@yadro.com

Closes #212 Signed-off-by: Marina Biryukova <m.biryukova@yadro.com>
mbiryukova self-assigned this 2025-02-27 09:29:33 +00:00
mbiryukova added 1 commit 2025-02-27 09:29:33 +00:00
Signed-off-by: Marina Biryukova <m.biryukova@yadro.com>
requested reviews from storage-services-developers, storage-services-committers 2025-02-27 09:29:33 +00:00
mbiryukova force-pushed feature/cors_container from 186578c264 to de5f362867 2025-02-27 10:04:05 +00:00 Compare
dkirillov reviewed 2025-02-28 09:08:48 +00:00
@ -105,6 +110,7 @@ type (
bufferMaxSizeForPut uint64
namespaceHeader string
defaultNamespaces []string
corsSet bool
Member

Probably we can combine all cors setting in one struct and use one param in settings instead of corsSet, corsAllowOrigin etc ?

Probably we can combine all cors setting in one struct and use one param in settings instead of `corsSet`, `corsAllowOrigin` etc ?
dkirillov marked this conversation as resolved
@ -262,0 +260,4 @@
func (a *app) initContainers(ctx context.Context) {
corsCnrInfo, err := a.fetchContainerInfo(ctx, cfgContainersCORS)
if err != nil {
a.log.Fatal(logs.CouldNotFetchCORSContainerInfo, zap.Error(err), logs.TagField(logs.TagApp))
Member

Do we need fatal here if cors.* config variables are set?

Do we need `fatal` here if `cors.*` config variables are set?
Author
Member

Seems that no, but cors.* settings are SIGHUP reloadable and container is not

Seems that no, but `cors.*` settings are SIGHUP reloadable and container is not
dkirillov marked this conversation as resolved
@ -610,3 +626,3 @@
// Configure router.
a.configureRouter(handle)
a.configureRouter()
Member

Probably we can move invocation handler.New into a.configureRouter to be more explicit the fact of this two calls must be done in strict order?

Probably we can move invocation `handler.New` into `a.configureRouter` to be more explicit the fact of this two calls must be done in strict order?
dkirillov marked this conversation as resolved
@ -1138,0 +1161,4 @@
return &data.BucketInfo{
CID: id,
HomomorphicHashDisabled: container.IsHomomorphicHashingDisabled(res),
Member

I'ms not sure if we really need this. Probably we can return just cid.ID. Yes in s3-gw this is used (but there we write to such container so we have to know IsHomomorphicHashingDisabled)

I'ms not sure if we really need this. Probably we can return just `cid.ID`. Yes in s3-gw this is used (but there we write to such container so we have to know `IsHomomorphicHashingDisabled`)
dkirillov marked this conversation as resolved
@ -0,0 +54,4 @@
corsRule := h.config.CORS()
if corsRule != nil {
setCORSHeadersFromRule(c, corsRule)
Member

Should we use the same logic as below even when we use overrides from config?

Should we use the same logic as below even when we use overrides from config?
@ -0,0 +246,4 @@
}
if headErr != nil {
return oid.ID{}, headErr
Member

If we want to return error when any head is failed we should return true on 238 line.
For now we return this error only if it occurred for last object in search, but this last object can be different.

If we want to return error when any head is failed we should `return true` on 238 line. For now we return this error only if it occurred for last object in search, but this last object can be different.
dkirillov marked this conversation as resolved
@ -70,7 +67,7 @@ func (x *FrostFS) CreateObject(ctx context.Context, prm handler.PrmObjectCreate)
prmPut.UseBearer(*prm.BearerToken)
}
idObj, err := x.pool.PutObject(qostagging.ContextWithIOTag(ctx, clientIOTag), prmPut)
Member

Why so?

Why so?
Author
Member

client is the default value of tag, only internal needs to be explicitly set. Did the same as in other services

`client` is the default value of tag, only `internal` needs to be explicitly set. Did the same as in other services
dkirillov marked this conversation as resolved
mbiryukova force-pushed feature/cors_container from de5f362867 to 26aa71b074 2025-03-10 08:04:08 +00:00 Compare
mbiryukova force-pushed feature/cors_container from 26aa71b074 to 9ef6b06e91 2025-03-10 15:13:32 +00:00 Compare
dkirillov reviewed 2025-03-11 07:56:17 +00:00
@ -0,0 +283,4 @@
return versionID1.EncodeToString() < versionID2.EncodeToString()
}
return unixTime1 < unixTime2
Member

Do we have guarantee that timestamp is always unix time (seconds, and not milliseconds)?

Do we have guarantee that timestamp is always unix time (seconds, and not milliseconds)?
dkirillov approved these changes 2025-03-11 07:57:08 +00:00
dkirillov left a comment
Member

LGTM, but see comments

LGTM, but see comments
alexvanin added this to the v0.33.0 milestone 2025-03-11 08:47:08 +00:00
alexvanin approved these changes 2025-03-12 06:33:54 +00:00
alexvanin merged commit 9ef6b06e91 into master 2025-03-12 06:33:58 +00:00
alexvanin deleted branch feature/cors_container 2025-03-12 06:34:01 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-http-gw#220
No description provided.