Priyesh Karatha created HDDS-16006:
--------------------------------------
Summary: S3 PutBucketLifecycleConfiguration rejects valid
configurations containing past dates, ExpiredObjectDeleteMarker, and
NoncurrentVersionExpiration
Key: HDDS-16006
URL: https://issues.apache.org/jira/browse/HDDS-16006
Project: Apache Ozone
Issue Type: Improvement
Components: S3, s3gateway
Reporter: Priyesh Karatha
Assignee: Priyesh Karatha
PutBucketLifecycleConfiguration fails with HTTP 400 InvalidRequest for three
classes of valid S3 lifecycle configurations, causing 5 failures in the S3
compatibility test suite
* test_lifecycle_set_date
* test_lifecycle_set_deletemarker
* test_lifecycle_set_empty_filter
* test_lifecycle_set_filter
* test_lifecycle_set_noncurrent
1. Past expiration dates — OmLCExpiration.valid() rejects any <Date> value
earlier than the lifecycle configuration's creation time. AWS allows past
dates; they are semantically equivalent to "expire immediately" and are
commonly used in configuration templates.
2. <ExpiredObjectDeleteMarker> — This S3 expiration element (used to clean up
delete markers in versioned buckets) is not parsed by the JAXB model. The
<Expiration> block is deserialized with both days and date as null, which
causes OmLCExpiration.valid() to throw "Either 'days' or 'date' should be
specified". AWS returns HTTP 200 for this configuration.
3. <NoncurrentVersionExpiration> — This element is not parsed at all. Rules
that contain only <NoncurrentVersionExpiration> end up with an empty actions
list, failing the "At least one action" check in OmLCRule.valid(). AWS returns
HTTP 200.
Root cause
The validation logic in OmLCExpiration is stricter than the S3 spec. The JAXB
model in S3LifecycleConfiguration does not model ExpiredObjectDeleteMarker or
NoncurrentVersionExpiration, which are valid S3 lifecycle elements that Ozone
does not yet enforce.
Fix
- Remove the "date must be in the future" check from OmLCExpiration.valid().
The midnight-UTC and ISO 8601 format checks are retained.
- Add <ExpiredObjectDeleteMarker> to the JAXB Expiration class. When it is the
only expiration element (days and date both absent), the expiration is treated
as an unsupported action and excluded from the OM rule.
- Add <NoncurrentVersionExpiration> to the JAXB Rule class. Rules whose only
actions are unsupported are skipped when building the OmLifecycleConfiguration.
If all rules in the request are unsupported-only, the request is accepted (HTTP
200) without persisting anything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]