[Bug] Decompression leaves metadata that makes recompression throw and corrupt the content type
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- csharp
- Domain
- backend, distributed-systems
Research direction
Start with CompressPayloadTransformer.Unwrap, UnwrapAsync, Wrap, and WrapAsync; the issue identifies these methods and the duplicate originalContentType metadata as the failure. Reproduce with a non-empty body above the compression threshold and cover sync, async, and mixed calls. Done when recompressing after decompression succeeds and a failed wrap preserves the restored body and content type.
Written by the indexing model from the issue text.
Description
At c4e128c4f09c068e930a8165cb37f3880840edbe, CompressPayloadTransformer.Unwrap and UnwrapAsync restore the original ContentType and body but leave Bag["originalContentType"] behind. Wrap and WrapAsync add that key with Dictionary.Add.
A valid Wrap -> Unwrap -> Wrap sequence on the same message therefore throws ArgumentException for the duplicate key on the second compression. This affects forwarding or recompressing a message after inspection. The second Wrap also changes Header.ContentType before throwing, leaving an inconsistent message with an uncompressed body and compressed content type.
Verification: both unwrap methods were checked for cleanup, and both wrap methods use Add after assigning ContentType. No runtime execution is claimed. Reproduce with a non-empty body above the compression threshold: wrap with GZip, unwrap, then wrap again. The first round trip succeeds; the second wrap fails. Cover sync, async and mixed calls.
Expected: successful decompression should consume its compression bookkeeping header, or wrapping should safely replace metadata with a clearly defined ownership policy. Preserve the restored body and content type if wrapping fails.
Existing searches for compression original content type and CompressPayloadTransformer header found only unrelated completed #4432 (charset recognition).
- Dominant language
- C#
- Stars
- 2.5k
- Forks
- 301
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 89
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from BrighterCommand/Brighter
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
BrighterCommand/Brighter#4682 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BrighterCommand/Brighter#4672 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
BrighterCommand/Brighter#4668 ·
Maintainers usually reply within 1 day
-
0 - Backlog Documentation V10.X
Difficulty 1/5 Under an hour Newbie friendliness 88/100
BrighterCommand/Brighter#4650 ·
Maintainers usually reply within 1 day
-
.NET 0 - Backlog feature request help wanted V10.X
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
BrighterCommand/Brighter#4532 ·
Maintainers usually reply within 1 day
All issues in BrighterCommand/Brighter
Similar issues
-
bug effort:S P3
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
nightscout/nocturne#3093 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 3 days
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100