[ 
https://issues.apache.org/jira/browse/HDDS-16585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prince Raj updated HDDS-16585:
------------------------------
    Description: 
h3. Description

While testing {{{}PutBucketLifecycleConfiguration{}}}, I observed that when a 
lifecycle rule is rejected by OM validation, the S3 Gateway returns a generic 
{{Invalid Request}} message instead of the underlying validation reason.

This behavior is reproducible for multiple lifecycle validation scenarios, 
including:
 * Invalid {{.Trash}} / {{.Trash/}} prefix

 * Invalid FSO prefix

 * Expiration date with a timezone that does not resolve to *midnight UTC*

h3. Steps to Reproduce
h4. 1. Invalid Trash Prefix

Create a lifecycle configuration with {{.Trash/}} as the prefix:

 

 
{code:java}
{{aws s3api put-bucket-lifecycle-configuration \
--bucket <bucket-name> \
--lifecycle-configuration '{
"Rules": [{
"ID": "trash-prefix-slash",
"Status": "Enabled",
"Filter":
{ "Prefix": ".Trash/" }
,
"Expiration": {
"Date": "2026-09-10T00:00:00Z"
}
}]
}'}}
The same behavior can also be reproduced with:
 
{{"Filter": {
"Prefix": ".Trash"
}}}
{code}
 
h4. 2. Invalid FSO Prefix

The same generic error response is observed when an invalid FSO lifecycle 
prefix is provided.
h4. 3. Invalid UTC Timezone / Non-Midnight UTC

The same behavior is observed when the expiration date contains a timezone 
that, after conversion to UTC, does not represent {{{}00:00:00Z{}}}.
h3. Actual Result

The lifecycle configuration is correctly rejected with HTTP {{{}400{}}}, but 
the S3 response only contains a generic message:

 
{code:java}
{{<Code>InvalidRequest</Code>
<Message>Invalid Request</Message>}}{code}
The underlying validation reason is not exposed to the client.
h3. Expected Result

The request should continue to be rejected with HTTP {{{}400{}}}, but the S3 
error message should include the specific validation reason.

For example:

{{Lifecycle rule prefix cannot be trash root .Trash/}}

or:

{{Lifecycle configuration 'Date' must represent midnight UTC (00:00:00Z)}}

This would allow clients to understand and correct the invalid lifecycle 
configuration.
h3. Root Cause
 * OM validation methods throw {{OMException}} with a specific validation 
message.

 * {{BucketLifecycleHandler.putBucketLifecycleConfiguration()}} catches the 
{{OMException}} and creates an {{OS3Exception}} using the generic 
{{InvalidRequest}} error.

 * The underlying {{OMException.getMessage()}} is therefore not propagated to 
the S3 {{<Message>}} field.

 * Other S3 handlers append the underlying OM exception message, but lifecycle 
configuration handling currently returns only the static {{Invalid Request}} 
message.

h3. Suggested Fix

For lifecycle PUT validation failures, propagate the underlying OM exception 
message to the S3 error response, following the existing pattern used by other 
handlers.

For example:

 

{{setErrorMessage(... + ex.getMessage());}}

or use the appropriate {{withMessage(ex.getMessage())}} mechanism where 
applicable.
h3. Expected Behavior

The lifecycle configuration should remain rejected for invalid input, but the 
S3 response should provide the specific validation reason rather than a generic 
{{{}Invalid Request{}}}.

  was:
h3. Description

While testing {{{}PutBucketLifecycleConfiguration{}}}, I observed that when a 
lifecycle rule is rejected by OM validation, the S3 Gateway returns a generic 
{{Invalid Request}} message instead of the underlying validation reason.

This behavior is reproducible for multiple lifecycle validation scenarios, 
including:
 * Invalid {{.Trash}} / {{.Trash/}} prefix

 * Invalid FSO prefix

 * Expiration date with a timezone that does not resolve to *midnight UTC*

h3. Steps to Reproduce
h4. 1. Invalid Trash Prefix

Create a lifecycle configuration with {{.Trash/}} as the prefix:

 

{{aws s3api put-bucket-lifecycle-configuration \
  --bucket <bucket-name> \
  --lifecycle-configuration '\{
    "Rules": [{
      "ID": "trash-prefix-slash",
      "Status": "Enabled",
      "Filter": {
        "Prefix": ".Trash/"
      },
      "Expiration": \{
        "Date": "2026-09-10T00:00:00Z"
      }
    }]
  }'}}

The same behavior can also be reproduced with:

 

{{"Filter": \{
  "Prefix": ".Trash"
}}}
h4. 2. Invalid FSO Prefix

The same generic error response is observed when an invalid FSO lifecycle 
prefix is provided.
h4. 3. Invalid UTC Timezone / Non-Midnight UTC

The same behavior is observed when the expiration date contains a timezone 
that, after conversion to UTC, does not represent {{{}00:00:00Z{}}}.
h3. Actual Result

The lifecycle configuration is correctly rejected with HTTP {{{}400{}}}, but 
the S3 response only contains a generic message:

 

{{<Code>InvalidRequest</Code>
<Message>Invalid Request</Message>}}

The underlying validation reason is not exposed to the client.
h3. Expected Result

The request should continue to be rejected with HTTP {{{}400{}}}, but the S3 
error message should include the specific validation reason.

For example:

 

{{Lifecycle rule prefix cannot be trash root .Trash/}}

or:

 

{{Lifecycle configuration 'Date' must represent midnight UTC (00:00:00Z)}}

This would allow clients to understand and correct the invalid lifecycle 
configuration.
h3. Root Cause
 * OM validation methods throw {{OMException}} with a specific validation 
message.

 * {{BucketLifecycleHandler.putBucketLifecycleConfiguration()}} catches the 
{{OMException}} and creates an {{OS3Exception}} using the generic 
{{InvalidRequest}} error.

 * The underlying {{OMException.getMessage()}} is therefore not propagated to 
the S3 {{<Message>}} field.

 * Other S3 handlers append the underlying OM exception message, but lifecycle 
configuration handling currently returns only the static {{Invalid Request}} 
message.

h3. Suggested Fix

For lifecycle PUT validation failures, propagate the underlying OM exception 
message to the S3 error response, following the existing pattern used by other 
handlers.

For example:

 

{{setErrorMessage(... + ex.getMessage());}}

or use the appropriate {{withMessage(ex.getMessage())}} mechanism where 
applicable.
h3. Expected Behavior

The lifecycle configuration should remain rejected for invalid input, but the 
S3 response should provide the specific validation reason rather than a generic 
{{{}Invalid Request{}}}.


> PutBucketLifecycleConfiguration returns generic Invalid Request for .Trash 
> prefix rejection
> -------------------------------------------------------------------------------------------
>
>                 Key: HDDS-16585
>                 URL: https://issues.apache.org/jira/browse/HDDS-16585
>             Project: Apache Ozone
>          Issue Type: Bug
>            Reporter: Prince Raj
>            Priority: Major
>
> h3. Description
> While testing {{{}PutBucketLifecycleConfiguration{}}}, I observed that when a 
> lifecycle rule is rejected by OM validation, the S3 Gateway returns a generic 
> {{Invalid Request}} message instead of the underlying validation reason.
> This behavior is reproducible for multiple lifecycle validation scenarios, 
> including:
>  * Invalid {{.Trash}} / {{.Trash/}} prefix
>  * Invalid FSO prefix
>  * Expiration date with a timezone that does not resolve to *midnight UTC*
> h3. Steps to Reproduce
> h4. 1. Invalid Trash Prefix
> Create a lifecycle configuration with {{.Trash/}} as the prefix:
>  
>  
> {code:java}
> {{aws s3api put-bucket-lifecycle-configuration \
> --bucket <bucket-name> \
> --lifecycle-configuration '{
> "Rules": [{
> "ID": "trash-prefix-slash",
> "Status": "Enabled",
> "Filter":
> { "Prefix": ".Trash/" }
> ,
> "Expiration": {
> "Date": "2026-09-10T00:00:00Z"
> }
> }]
> }'}}
> The same behavior can also be reproduced with:
>  
> {{"Filter": {
> "Prefix": ".Trash"
> }}}
> {code}
>  
> h4. 2. Invalid FSO Prefix
> The same generic error response is observed when an invalid FSO lifecycle 
> prefix is provided.
> h4. 3. Invalid UTC Timezone / Non-Midnight UTC
> The same behavior is observed when the expiration date contains a timezone 
> that, after conversion to UTC, does not represent {{{}00:00:00Z{}}}.
> h3. Actual Result
> The lifecycle configuration is correctly rejected with HTTP {{{}400{}}}, but 
> the S3 response only contains a generic message:
>  
> {code:java}
> {{<Code>InvalidRequest</Code>
> <Message>Invalid Request</Message>}}{code}
> The underlying validation reason is not exposed to the client.
> h3. Expected Result
> The request should continue to be rejected with HTTP {{{}400{}}}, but the S3 
> error message should include the specific validation reason.
> For example:
> {{Lifecycle rule prefix cannot be trash root .Trash/}}
> or:
> {{Lifecycle configuration 'Date' must represent midnight UTC (00:00:00Z)}}
> This would allow clients to understand and correct the invalid lifecycle 
> configuration.
> h3. Root Cause
>  * OM validation methods throw {{OMException}} with a specific validation 
> message.
>  * {{BucketLifecycleHandler.putBucketLifecycleConfiguration()}} catches the 
> {{OMException}} and creates an {{OS3Exception}} using the generic 
> {{InvalidRequest}} error.
>  * The underlying {{OMException.getMessage()}} is therefore not propagated to 
> the S3 {{<Message>}} field.
>  * Other S3 handlers append the underlying OM exception message, but 
> lifecycle configuration handling currently returns only the static {{Invalid 
> Request}} message.
> h3. Suggested Fix
> For lifecycle PUT validation failures, propagate the underlying OM exception 
> message to the S3 error response, following the existing pattern used by 
> other handlers.
> For example:
>  
> {{setErrorMessage(... + ex.getMessage());}}
> or use the appropriate {{withMessage(ex.getMessage())}} mechanism where 
> applicable.
> h3. Expected Behavior
> The lifecycle configuration should remain rejected for invalid input, but the 
> S3 response should provide the specific validation reason rather than a 
> generic {{{}Invalid Request{}}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to