fix: exclude content-length and content-type from DeleteObject signed…

[r-oswald]

DeleteObject is missing from the skip-list in request_trait.rs headers(), so requests get content-length: 0 and content-type: text/plain signed.

L7 proxies strip Content-Length: 0 per RFC 7230 §3.3.2 so you get a signature mismatch.

So this merge request strips this header on delete request.

---

This change is 

Summary by CodeRabbit

• Bug Fixes
  • Improved handling of delete requests to ensure they are properly formatted without unnecessary headers, fixing an issue where delete operations may have been incorrectly processed.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 142fca81-d345-4441-8381-4545092cec18

📥 Commits

Reviewing files that changed from the base of the PR and between b584ce7 and d172398.

📒 Files selected for processing (1)

• s3/src/request/request_trait.rs

---

📝 Walkthrough

Walkthrough

This PR adds an explicit no-op arm for Command::DeleteObject in the Request::headers method to prevent DeleteObject requests from receiving content-length and content-type headers that should not be included in such requests.

Changes

DeleteObject header exclusion

Layer / File(s)	Summary
DeleteObject header exclusion s3/src/request/request_trait.rs	Command::DeleteObject now matches explicitly with an empty arm in the headers method's command match, preventing these requests from falling into the default branch that injects CONTENT_LENGTH and CONTENT_TYPE headers.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• durch/rust-s3#455: Both PRs modify s3/src/request/request_trait.rs in Request::headers() to add explicit Command::<...> => {} arms (HeadObject vs DeleteObject) preventing those commands from falling into the fallback that injects CONTENT_LENGTH/CONTENT_TYPE and related signed headers.

Poem

🐰 A hop through headers clean and bright,
DeleteObject takes its rightful flight,
No length, no type shall weigh it down,
Just delete that bucket's crown! 🎯

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely summarizes the main change: excluding content-length and content-type headers from DeleteObject signed requests. It directly reflects the primary purpose of the one-line code addition.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[brownian-motion-v0]

Brownian Motion (Brass)

Recommendation: Proceed

Summary: PR addresses header signing issue for DeleteObject requests effectively.
Risk: Medium · Confidence: 80%

Highlights

• Clear identification of the problem
• Concise implementation
• Relevant RFC reference

Unknowns

• Potential impact on existing clients using DeleteObject

Next actions

• Keep: the change to exclude content-length and content-type headers
• Drop: any additional complexity not related to the core fix
• Add: tests to confirm the behavior of DeleteObject requests

Reflection questions

• What core assumption underpins this PR's approach?
• How does this change align with the project's longer-term goals?
• Could there be a simpler way to achieve the primary objective here?