-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object Lock Error Responses Wrong/Weird #498
Comments
Additional unmapped or incorrect errors discovered in tests: https://review.dev.storj.io/c/storj/edge/+/14432
|
Jeremy mentioned that S3 returns
|
Change miniogw: map GetObjectRetention no retention errors mentions this issue. |
this maps metaclient.ErrRetentionNotFound errors to a minio error of "InvalidRequest" so the client sees an appropriate response instead of an internal server error. Updates storj/edge#498 Change-Id: I0d86d308c5cfaf449014b0d87da48af9406a1cca
AWS S3 error response research: GetObjectLockConfiguration on bucket without object lockS3: HTTP 404: ObjectLockConfigurationNotFoundError: Object Lock configuration does not exist for this bucket Us: HTTP 400: "InvalidRequest: Bucket is missing Object Lock Configuration" This is a big difference we should probably fix. GetObjectRetention on object without any (bucket has object lock configuration)S3: HTTP 404: "NoSuchObjectLockConfiguration: The specified object does not have a ObjectLock configuration" Us: HTTP 400: "InvalidRequest: Object is missing retention configuration" This is a big difference we should probably fix. GetObjectRetention on object without any (bucket has no object lock configuration)S3: HTTP 400: "InvalidRequest: Bucket is missing Object Lock Configuration" Us: HTTP 400: "InvalidRequest: Object is missing retention configuration" PutObjectLockConfiguration on bucket without versioning enabledS3: HTTP 409: InvalidBucketState: Versioning must be 'Enabled' on the bucket to apply a Object Lock configuration US: HTTP 501: Unimplemented PutObject with retain date in the pastS3: HTTP 400: InvalidArgument: The retain until date must be in the future! Us: MalformedXML. Might be a minio issue. PutObject with invalid modeS3: HTTP 400: InvalidArgument: Unknown wormMode directive. Us: HTTP 400: InvalidRequest Might not be worth fixing the code when the status is the same. PutObject with correct retention settings, versioning not enabled on bucket and no bucket lock configuration:S3: HTTP 400: InvalidRequest: Bucket is missing ObjectLockConfiguration Us: HTTP 500: "cannot specify Object Lock settings when uploading into a bucket without Versioning enabled" This is critical to fix as it's unmapped (defaults to 500) resulting in misleading clients to retry with the same result. PutObject with correct retention settings, versioning is enabled on bucket and no bucket lock configuration:S3: HTTP 400: InvalidRequest: Bucket is missing ObjectLockConfiguration Us: HTTP 500: ""cannot specify Object Lock settings when uploading into a bucket without Object Lock enabled" This is critical to fix as it's unmapped (defaults to 500) resulting in misleading clients to retry with the same result. DeleteObject locked versionS3: HTTP 403: AccessDenied: Access Denied because object protected by object lock. Us: HTTP 403: AccessDenied: Access Denied. Adjusting the error message might be helpful to users. PutBucketVersioning suspend bucket with existing object lock configurationS3: HTTP 409: InvalidBucketState: An Object Lock configuration is present on this bucket, so the versioning state cannot be changed Us: HTTP 403: AccessDenied: Access Denied: This is probably worth fixing to make it more descriptive, at least. |
Change miniogw: fix error responses for missing lock or retention mentions this issue. |
Change satellite/metainfo: return object lock messages consistent with S3 mentions this issue. |
Change private/metaclient: remap object lock errors mentions this issue. |
Change miniogw: return 404 for GetObjectLockConfig if no lock found mentions this issue. |
This endpoint should return a 404 for when lock config is not found, instead of a 400. Additionally, fix tests to use the object API layer for testing GetObjectLockConfig. Gateway tests should not be testing the metaclient endpoints, since that's uplink domain. Updates storj/edge#498 Change-Id: Ic7cbb3f217acf086884c8ebe935bd9fc976c1680
this also fixes a case where Commit calls didn't convert to known errors and caused unmapped errors on gateway. Updates storj/edge#498 Change-Id: I07907185c26559805c342be584b3b2c8bc776800
Change miniogw: fix up mappings to latest uplink code mentions this issue. |
- use the new uplink ErrRetentionNotFound error type. Additionally this should return a 404 with the right status S3 uses. Note that if the bucket has no lock enabled, GetObjectRetention does the same as S3 and return a 400 response bucket lock not configured. - uplink ErrBucketNoLock, ErrNoObjectLockConfiguration, and ErrBucketNoVersioningObjectLock should all map to miniogw.ErrRetentionNotFound, a 400 status. We will need to also map ObjectLockDisabled (for when the feature is disabled entirely) as well as ProjectLockDisabled to this same error, but these will come in a later change. Updates storj/edge#498 Change-Id: Ic3702e24cb3e8f177eac303ccb3f9869a8de96b5
The following object lock related actions returned an "unauthorized" error rather than the appropriate error.
aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Suspended --endpoint-url https://gateway.qa.storjshare.io
See columns G, H, I for more context: https://docs.google.com/spreadsheets/d/1Yfz1sSTRD2nTRAkgGJ27aAv7wTMJCd-74fJlujdNPBw/edit?gid=0#gid=0
The text was updated successfully, but these errors were encountered: